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 <svenpanne@gmail.com> wrote:
... 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