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