<div dir="ltr">Artyom: That's precisely the point. The true IEEE754 variants where precision does matter should be part of a different class. What Edward and Yitz want is an "optimized" multiply-add where the semantics is the same but one that goes faster.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 4, 2015 at 10:40 AM, Artyom <span dir="ltr"><<a href="mailto:yom@artyom.me" target="_blank">yom@artyom.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    On 05/04/2015 08:36 PM, Levent Erkok wrote:<br>
    <blockquote type="cite">
      <div dir="ltr">In particular, the compiler should be free to
        substitute "a*b+c" with "mulAccum a b c".<br>
      </div>
    </blockquote></span>
    But isn't it unacceptable in some cases? For instance, in this case
    (taken from Wikipedia):<br>
    <blockquote type="cite">If <span><i>x</i><sup>2</sup>
        − <i>y</i><sup>2</sup></span> is evaluated as <span>((<i>x</i>×<i>x</i>) − <i>y</i>×<i>y</i>)</span>
      using fused multiply–add, then the result may be negative even
      when <span><i>x</i> = <i>y</i></span> due to the
      first multiplication discarding low significance bits. This could
      then lead to an error if, for instance, the square root of the
      result is then evaluated.</blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>