While checking for floating-point overflow and underflow conditions, I tried to create a somewhat reliable cross-platform Infinity with the literal "1e100000". When GHC 6.4.1 reads this literal, it goes into a deep trance and consumes huge amounts of memory. Shouldn't it immediately recognize such a thing as Infinity? Is there a better way to check for Infinity? I have not yet figured out how to check for NaN at all - because it is not equal to itself. Any suggestions? BTW, I notice that Simon PJ proposed literals for Infinity and Nan several years ago: http://www.haskell.org/pipermail/haskell/2001-August/007753.html Did anything ever come out of this? Regards, Yitzchak
On 9/29/05, Yitzchak Gale <gale@sefer.org> wrote:
While checking for floating-point overflow and underflow conditions, I tried to create a somewhat reliable cross-platform Infinity with the literal "1e100000".
When GHC 6.4.1 reads this literal, it goes into a deep trance and consumes huge amounts of memory. Shouldn't it immediately recognize such a thing as Infinity?
I think it is equivalent to (fromRational 1e100000), and (1e100000 :: Rational) can take a substantial amount of space. Is there a better way to check for Infinity? I
have not yet figured out how to check for NaN at all - because it is not equal to itself. Any suggestions?
Did you try isNaN and isInfinite? I don't have much experience with these functions myself. Best regards Tomasz
I wrote:
While checking for floating-point overflow and underflow conditions, I tried to create... Infinity with the literal "1e100000"... Is there a better way to check for Infinity?
Tomasz Zielonka wrote:
Did you try isNaN and isInfinite?
Oops. Thanks! Thanks also to Lennart Augustsson. I wrote:
...I tried to create... Infinity with the literal "1e100000"... GHC... goes into a deep trance...
Tomasz Zielonka wrote:
...it is equivalent to (fromRational 1e100000), and (1e100000 :: Rational) can take a substantial amount of space.
I see. That explains it. Thanks! Regards, Yitz
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 Yitzchak Gale wrote:
While checking for floating-point overflow and underflow conditions, I tried to create a somewhat reliable cross-platform Infinity with the literal "1e100000".
When GHC 6.4.1 reads this literal, it goes into a deep trance and consumes huge amounts of memory. Shouldn't it immediately recognize such a thing as Infinity?
Is there a better way to check for Infinity? I have not yet figured out how to check for NaN at all - because it is not equal to itself. Any suggestions?
BTW, I notice that Simon PJ proposed literals for Infinity and Nan several years ago:
http://www.haskell.org/pipermail/haskell/2001-August/007753.html
Did anything ever come out of this?
Regards, Yitzchak _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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
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
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
But they all have a largest and smallest possible value, as I have already indicated. On Sun, Oct 02, 2005 at 04:35:02PM +0200, Lennart Augustsson wrote:
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
The RealFloat class has a number of methods for testing various properties of a FP number: isNaN :: a -> Bool isInfinite :: a -> Bool isDenormalized :: a -> Bool isNegativeZero :: a -> Bool isIEEE :: a -> Bool If you really want to create an Infinity, I suggest 1/0, but not all FP formats support it (IEEE754 does). -- Lennart Yitzchak Gale wrote:
While checking for floating-point overflow and underflow conditions, I tried to create a somewhat reliable cross-platform Infinity with the literal "1e100000".
When GHC 6.4.1 reads this literal, it goes into a deep trance and consumes huge amounts of memory. Shouldn't it immediately recognize such a thing as Infinity?
Is there a better way to check for Infinity? I have not yet figured out how to check for NaN at all - because it is not equal to itself. Any suggestions?
BTW, I notice that Simon PJ proposed literals for Infinity and Nan several years ago:
http://www.haskell.org/pipermail/haskell/2001-August/007753.html
Did anything ever come out of this?
Regards, Yitzchak _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
participants (5)
-
Frederik Eaton -
Jacques Carette -
Lennart Augustsson -
Tomasz Zielonka -
Yitzchak Gale