<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>