Folding constants for floats

[Carter Schonwald]

I emphatically and forcefully agree with Isaac.

Thanks for articulating these issues much better than I could.


On Tue, Jan 14, 2014 at 2:54 PM, Isaac Dupree <
ml at isaac.cedarswampstudios.org> wrote:

> On 01/14/2014 11:48 AM, Sven Panne wrote:
>
>> My point was: As much as I propose to keep these current semantics,
>> there might be users who care more about performance than
>> IEEE-754-conformance.
>>
>
> Adding a -ffast-math flag could be fine IMHO.
>
>
>  For those, relatively simple semantics could be:
>> Regarding optimizations, numbers are considered "mathematical"
>> numbers, ignoring any rounding and precision issues,
>>
>
> How do you plan to constant-fold things like "log(cos(pi**pi))" without
> rounding?
>
> 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: http://gcc.gnu.org/wiki/FloatingPointMath
>
> Probably it's best not to touch floating point optimization without
> understanding all these issues.
>
> 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()).
>
> -Isaac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/4d39d390/attachment-0001.html>