I've previously mentioned that I would like to see an 'instance Bounded Double' etc., as part of the standard, which would use 1/0 for maxBound, or the largest possible value (there must be one!) for platforms where that is not possible. I don't see a problem with looking at Double values as if they were bounded by -infinity and +infinity.
On Thu, Sep 29, 2005 at 09:11:25PM +0300, Yitzchak Gale wrote: > Hi Jacques, > > Thanks also to you for a most interesting reply. > > This same discussion has taken place on the > discussion list of every modern general-purpose > programming language. > > The same points are always raised and argued, and > the conclusion is always the same: floating point > exceptions should raise exceptions. Programs that > are so sensitive that the tiny overhead makes a > difference should use numeric libraries, unboxed > types, FFI, and the like. > > In Haskell also, it looks like the infrastructure > was already laid in the Control.Exception module. > I hope we will soon be using it. > > I personally would like also to see alternative > functions that return values in the Error monad. > > Regards, > Yitz > > On Thu, Sep 29, 2005 at 03:13:27PM +0300, Jacques Carette wrote: > > The IEEE 754 standard says (fairly clearly) that +1.0 / +0.0 is one of > > the most 'stable' definitions of Infinity (in Float at least). > > Throwing an exception is also regarded as a possibility in IEEE 754, but > > it is expected that that is not the default, as experience shows that > > that is a sub-optimal default. Mathematical software (Maple, > > Mathematica, Matlab) have generally moved in that direction. > > > > Almost all hardware implementations of float arithmetic now default to > > IEEE 754 arithmetic. Having the arithmetic do 'something else' involves > > more CPU cycles, so users should generally complain if their system's > > arithmetic differs from IEEE 754 arithmetic without some deep reason to > > do so [there are some; read and understand William Kahan's papers for > > these]. > > > > Jacques > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
