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