maybe so, but having a semantics by default is huge, and honestly i'm not
super interested in optimizations that merely change one infinity for
another. What would the alternative semantics be? Whatever it is, how will
we communicate it to our users? GHC's generally been (by accidenta) IEEE
compliant, changing that will possibly break someones code! (perhaps). Also
who's going to specify this alternative semantics and educate everyone
about it?
the thing is floating point doesn't act like most other models of numbers,
they have a very very non linear grid of precision across as HUGE dynamic
range. Pretending theyre something they're not is the root of most problems
with them.
either way, its a complex problem that nees to be carefully sorted out
On Tue, Jan 14, 2014 at 3:03 AM, Sven Panne
... and let's not forget about such fun stuff as IEEE's -0, e.g.:
1/(-1 * 0) => -Infinity 1/(0 + (-1 * 0)) => Infinity
If we take the standpoint that Haskell's Float and Double types correspond to IEEE 754 floating point numbers, there is almost no mathematical equivalence which holds, and consequently almost all folding or other optimizations will be wrong. One can do all these things behind a flag (trading IEEE compatibility for better code), but this shouldn't be done by default IMHO. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs