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 < m...@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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
