<div dir="ltr">I emphatically and forcefully agree with Isaac. <div><br></div><div style>Thanks for articulating these issues much better than I could.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 2:54 PM, Isaac Dupree <span dir="ltr"><<a href="mailto:ml@isaac.cedarswampstudios.org" target="_blank">ml@isaac.cedarswampstudios.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/14/2014 11:48 AM, Sven Panne wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My point was: As much as I propose to keep these current semantics,<br>
there might be users who care more about performance than<br>
IEEE-754-conformance.<br>
</blockquote>
<br></div>
Adding a -ffast-math flag could be fine IMHO.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For those, relatively simple semantics could be:<br>
Regarding optimizations, numbers are considered "mathematical"<br>
numbers, ignoring any rounding and precision issues,<br>
</blockquote>
<br></div>
How do you plan to constant-fold things like "log(cos(pi**pi))" without rounding?<br>
<br>
I checked C, and apparently the optimizer is entitled to assume the default floating-point control modes (e.g. rounding mode, quiet/signaling NaN) are in effect except in scopes where "#pragma STDC FENV_ACCESS ON" is given.  However the standard does not entitle the optimizer to change rounding in any other way.  This is sufficient for constant-folding in regions where FENV_ACCESS is off.  GCC also has flags to control floating-point optimization: <a href="http://gcc.gnu.org/wiki/FloatingPointMath" target="_blank">http://gcc.gnu.org/wiki/<u></u>FloatingPointMath</a><br>


<br>
Probably it's best not to touch floating point optimization without understanding all these issues.<br>
<br>
Hmm, I can't see how non-default floating point control mode is compatible with Haskell's purity... Even without optimizations, (1/3 :: Double) could evaluate to two different values in the same program if the floating-point rounding mode changes during execution (e.g. by C fesetenv()).<span class="HOEnZb"><font color="#888888"><br>


<br>
-Isaac<br>
</font></span></blockquote></div><br></div>