Not all FP representations have infinity, and even if
they do, they might only have one infinity.
-- Lennart
Frederik Eaton wrote:
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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
