Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
Henning Thielemann wrote: On Fri, 5 Nov 2004, Robert Dockins wrote: What IEEE has done is shoehorned in some values that aren't really numbers into their representation (NaN certainly; one could make a convincing argument that +Inf and -Inf aren't numbers). I wonder why Infinity has a sign in IEEE floating processing, as well as 0. To support this behaviour uniformly one would need a +0 or -0 offset for each number, which would lead straightforward to non-standard analysis ... IEEE floats support both affine (signed) and projective (unsigned) infinity. Projective is more natural in some circumstances (since you can do a Möbius transformation from a circle to an infinite line). Haskell, on the othet hand, does not let you specify the mode. -- Lennart ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
Henning Thielemann wrote: >I wonder why Infinity has a sign in IEEE floating processing, as well as >0. To support this behaviour uniformly one would need a +0 or -0 offset >for each number, which would lead straightforward to non-standard analysis >... See "Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit" by William Kahan, in The State of the Art in Numerical Analysis, (eds. Iserles and Powell), Clarendon Press, Oxford, 1987. (Note that I have not read this paper. However, Kahan was the primary architect of the IEEE floating point standard, so you can be pretty sure the reasons given in the paper are also the reasons IEEE floating point has signed zero.) A good online presentation which mentions all kinds of interesting floating point pathologies, including those discussed in the above paper, is "How Java’s Floating-Point Hurts Everyone Everywhere" (http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf). >[...] Thus (a-b) is not the same as -(b-a) for IEEE floats! Nor is x*0 equal to 0 for every x; nor does x == y imply f(x) == f(y) for every x, y, f; nor is addition or multiplication associative. There aren't many identities that do hold of floating point numbers. -- Ben ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
MR K P SCHUPKE wrote: >Why is there no Irrational class. This would make more sense for >Floats and Doubles than the fraction based Rational class. We could >also add an implementation of infinite precision irrationals using >a pair of Integers for exponent and mantissa. That would just be a subset of the rationals, namely the dyadic rationals (mantissa / 2^^exponent). -- Ben ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
On Fri, Nov 05, 2004 at 02:53:01PM +, MR K P SCHUPKE wrote: > >My guess is because irrationals can't be represented on a discrete computer > > Well, call it arbitrary precision floating point then. Having built in > Integer support, it does seem odd only having Float/Double/Rational... There are a number of choices to be made in making such an implementation. It would be handy, but it makes sense that it's more than the Haskell designers wanted to specify initially. It would make a nice library if you want to write it. Peace, Dylan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
>[...] Thus (a-b) is not the same as -(b-a) for IEEE floats! Nor is x*0 equal to 0 for every x; nor does x == y imply f(x) == f(y) for every x, y, f; nor is addition or multiplication associative. There aren't many identities that do hold of floating point numbers. Yes, but they DO hold for Rational (I believe). The argument against NaN = 0 :% 0, Inf = 1 :% 0, etc. is that the otherwise valid identies for _Rational_ are disturbed. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
On Fri, 2004-11-05 at 13:57, Henning Thielemann wrote: > On Fri, 5 Nov 2004, Robert Dockins wrote: > > > What IEEE has done is shoehorned in some values that aren't really > > numbers into their representation (NaN certainly; one could make a > > convincing argument that +Inf and -Inf aren't numbers). > > I wonder why Infinity has a sign in IEEE floating processing, as well as > 0. To support this behaviour uniformly one would need a +0 or -0 offset > for each number, which would lead straightforward to non-standard analysis It is related to the decision to have signed infinity. One rationale is thus: The identity 1/(1/x) = x is only true for all IEEE floats x if we have signed 0. In particular if x is -infinity then 1/(-infinity) would be 0 and 1/0 = +infinity in the IEEE floating point system. So if we preserve the sign for overflow (+-infinity), we also need to preserve the sign for underflow (+-0) or other identities fail. Note that -0 == +0 See: What Every Computer Scientist Should Know About Floating Point Arithmetic http://citeseer.ist.psu.edu/goldberg91what.html page 183. Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
>My guess is because irrationals can't be represented on a discrete computer Well, call it arbitrary precision floating point then. Having built in Integer support, it does seem odd only having Float/Double/Rational... Keean. .. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
On Fri, 5 Nov 2004, Robert Dockins wrote: > What IEEE has done is shoehorned in some values that aren't really > numbers into their representation (NaN certainly; one could make a > convincing argument that +Inf and -Inf aren't numbers). I wonder why Infinity has a sign in IEEE floating processing, as well as 0. To support this behaviour uniformly one would need a +0 or -0 offset for each number, which would lead straightforward to non-standard analysis ... Prelude> 1/0.0 Infinity Prelude> -1/0.0 -Infinity Prelude> -0.0 -0.0 Prelude> 1.0-1.0 0.0 Prelude> -(1.0-1.0) -0.0 Thus (a-b) is not the same as -(b-a) for IEEE floats! ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
My guess is because irrationals can't be represented on a discrete computer (unless you consider a computaion, the limit of which is the irrational number in question). A single irrational might not just be arbitrarily long, but it may have an _infinite_ length representation! What you have described is arbitrary (not infinite) precision floating point. What IEEE has done is shoehorned in some values that aren't really numbers into their representation (NaN certainly; one could make a convincing argument that +Inf and -Inf aren't numbers). Perhaps it would make more sense to add constructors to the Rational type to represent these additional "values", ie, make Rational look like (edited from section 12.1 of the Report) data (Integral a) => Ratio a = a! :% a! | Nan | PosInf | NegInf deriving(Eq) type Rational = Ratio Integer This has the effect that pattern matching :% when the value is NaN etc. gives an error instead of doing bizarre things (by succeeding against non numeric values). This is an advantage or a disadvantage depending on your viewpoint. Unfortunately, that isn't how its defined in the Report, so it may not be an option. MR K P SCHUPKE wrote: I would be very careful of adding non-rationals to the Rational type. Why is there no Irrational class. This would make more sense for Floats and Doubles than the fraction based Rational class. We could also add an implementation of infinite precision irrationals using a pair of Integers for exponent and mantissa. Keean. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Double -> CDouble, realToFrac doesn't work
With GHCi, I get: Prelude Ratio> toRational (1.0/0) :: Ratio Integer 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 % 1 My personal gut feeling is that converting a NaN/Inf/etc to a fraction should be an error (although I see the point of being able to convert a e.g. Float to a Double and preserve such special values). Is it possible to provide a conversion function in the Floating or RealFloat class instead? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
>I would be very careful of adding non-rationals to the Rational type. Why is there no Irrational class. This would make more sense for Floats and Doubles than the fraction based Rational class. We could also add an implementation of infinite precision irrationals using a pair of Integers for exponent and mantissa. Keean. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Double -> CDouble, realToFrac doesn't work
On Thu, Nov 04, 2004 at 08:32:52PM +0100, Sven Panne wrote: > It's an old thread, but nothing has really happened yet, so I'd like to > restate and expand the question: What should the behaviour of toRational, > fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report > is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on > something. > Can we agree on the special Rational values below? I would be very careful of adding non-rationals to the Rational type. For one thing, it breaks the traditional rule for equality a % b == c % d iffa*d == b*c You'd need to look at all the instances for Ratio a that are defined. For instance, the Ord instance would require at least lots of special cases. And when would you expect 'x/0' to give +Infinity and when -Infinity? For IEEE floats, there are distinct representations of +0 and -0, which lets you know when you want which one. But for the Rational type there is no such distinction. The behaviour that '1 % 0' gives the error 'Ratio.% : zero denominator' is clearly specified by the Library Report. In the meantime, there are utility functions for dealing with IEEE floats (isNaN, etc.) Peace, Dylan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Double -> CDouble, realToFrac doesn't work
It's an old thread, but nothing has really happened yet, so I'd like to
restate and expand the question: What should the behaviour of toRational,
fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report
is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on something.
Can we agree on the special Rational values below?
Printing those values could be more consistent for these systems, too, BTW.
Cheers,
S.
Simon Peyton-Jones wrote:
| Hmmm, this is a little bit of a dark corner in the H98 report, but
there are
| probably other people on this list who know better than me. :-] The
problem
| is that 'realToFrac' is defined as 'fromRational . toRational', so the
first
| question is: How is 'toRational' supposed to handle NaN? One thing
coming to
| my mind is '0 :% 0', but this is normally a value which can't be
constructed.
| So the next question is: Would this be allowed? +Infinity and
-Infinity could
| be represented similarly then ('1 :% 0' and '(-1) :% 0'), and
'fromRational'
| could handle these values specially. But I can't believe that this has
been
| discussed for the first time. SPJ? Malcolm?
I don't recall a discussion about this, and a quick search in my mail
archive didn't turn up anything except the enclosed from George Russell.
I'm pretty ignorant about the dark corners of numerics, but it does seem
bad that passing through Rational loses information. Perhaps the Report
should specify normalised representations for +Inf, -Inf and NaN as
Rationals (1:%0, -1:%0, and 0:%0 seem like plausible candidates).
If someone wants to try this out, and send us a patch for the Rational
library, we could incorporate it. And so far as the report goes,
perhaps the Errata could contain a note identifying the issue, and
suggesting a solution. It's a bit late to *specify* a solution unless
we are really sure about it.
Simon
-Original Message-
From: George Russell [mailto:[EMAIL PROTECTED]
Sent: 25 February 2000 10:19
To: [EMAIL PROTECTED]
Subject: Floating-point nitpicking: floor(Inf) and floor(NaN)
floor(Inf) and floor(NaN) do not appear to be defined in Standard
Haskell.
(They both come down to "properFraction" which is only defined for
Ratio.)
This differs from (for example) the Standard ML Basis Library, where it
is specified that floor(Int) should raise Overflow and floor(NaN) should
raise Domain. Hence Hugs and GHC do different things.
Hugs returns floor(Inf) = 0 and floor(NaN) = 0
GHC returns floor(Inf) = very very large integer and floor(NaN) = even
larger
integer. (This is because the GHC implementation of properFraction
simply
ignores the case of Inf/NaN and treats the artificially high exponent
encoded
in those floating-point numbers as if it were a real one.)
My own opinion is that Standard ML is right here and that floor(x)
should
raise an exception (In Haskell terms, fail) when x does not correspond
to a
real number.
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Sven Panne
| Sent: 08 August 2004 17:02
| To: Hal Daume III
| Cc: GHC Users Mailing List; Malcom Wallace
| Subject: Re: Double -> CDouble, realToFrac doesn't work
|
| Hal Daume III wrote:
| > [...]
| > Prelude Foreign.C> (0 :: CDouble) / 0
| > NaN
| > Prelude Foreign.C> (0 :: Double) / 0
| > NaN
| > Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble
| > -Infinity
| >
| > yikes! the NaN got turned into a -Infinity!!!
| >
| > aside from manually checking for 'strange' Double/CDouble values and
| > wrapping realToFrac, is there a better way? also, does this count
as a
| > bug?
|
| Hmmm, this is a little bit of a dark corner in the H98 report, but
there are
| probably other people on this list who know better than me. :-] The
problem
| is that 'realToFrac' is defined as 'fromRational . toRational', so the
first
| question is: How is 'toRational' supposed to handle NaN? One thing
coming to
| my mind is '0 :% 0', but this is normally a value which can't be
constructed.
| So the next question is: Would this be allowed? +Infinity and
-Infinity could
| be represented similarly then ('1 :% 0' and '(-1) :% 0'), and
'fromRational'
| could handle these values specially. But I can't believe that this has
been
| discussed for the first time. SPJ? Malcolm?
|
| When you compile the stuff above with optimizations on, you get what
you've
| expected, thanks to RULES which shortcut the route via Rational
completely.
|
| Cheers,
| S.
|
| ___
| Glasgow-haskell-users mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Double -> CDouble, realToFrac doesn't work
| Hmmm, this is a little bit of a dark corner in the H98 report, but
there are
| probably other people on this list who know better than me. :-] The
problem
| is that 'realToFrac' is defined as 'fromRational . toRational', so the
first
| question is: How is 'toRational' supposed to handle NaN? One thing
coming to
| my mind is '0 :% 0', but this is normally a value which can't be
constructed.
| So the next question is: Would this be allowed? +Infinity and
-Infinity could
| be represented similarly then ('1 :% 0' and '(-1) :% 0'), and
'fromRational'
| could handle these values specially. But I can't believe that this has
been
| discussed for the first time. SPJ? Malcolm?
I don't recall a discussion about this, and a quick search in my mail
archive didn't turn up anything except the enclosed from George Russell.
I'm pretty ignorant about the dark corners of numerics, but it does seem
bad that passing through Rational loses information. Perhaps the Report
should specify normalised representations for +Inf, -Inf and NaN as
Rationals (1:%0, -1:%0, and 0:%0 seem like plausible candidates).
If someone wants to try this out, and send us a patch for the Rational
library, we could incorporate it. And so far as the report goes,
perhaps the Errata could contain a note identifying the issue, and
suggesting a solution. It's a bit late to *specify* a solution unless
we are really sure about it.
Simon
-Original Message-
From: George Russell [mailto:[EMAIL PROTECTED]
Sent: 25 February 2000 10:19
To: [EMAIL PROTECTED]
Subject: Floating-point nitpicking: floor(Inf) and floor(NaN)
floor(Inf) and floor(NaN) do not appear to be defined in Standard
Haskell.
(They both come down to "properFraction" which is only defined for
Ratio.)
This differs from (for example) the Standard ML Basis Library, where it
is specified that floor(Int) should raise Overflow and floor(NaN) should
raise Domain. Hence Hugs and GHC do different things.
Hugs returns floor(Inf) = 0 and floor(NaN) = 0
GHC returns floor(Inf) = very very large integer and floor(NaN) = even
larger
integer. (This is because the GHC implementation of properFraction
simply
ignores the case of Inf/NaN and treats the artificially high exponent
encoded
in those floating-point numbers as if it were a real one.)
My own opinion is that Standard ML is right here and that floor(x)
should
raise an exception (In Haskell terms, fail) when x does not correspond
to a
real number.
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Sven Panne
| Sent: 08 August 2004 17:02
| To: Hal Daume III
| Cc: GHC Users Mailing List; Malcom Wallace
| Subject: Re: Double -> CDouble, realToFrac doesn't work
|
| Hal Daume III wrote:
| > [...]
| > Prelude Foreign.C> (0 :: CDouble) / 0
| > NaN
| > Prelude Foreign.C> (0 :: Double) / 0
| > NaN
| > Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble
| > -Infinity
| >
| > yikes! the NaN got turned into a -Infinity!!!
| >
| > aside from manually checking for 'strange' Double/CDouble values and
| > wrapping realToFrac, is there a better way? also, does this count
as a
| > bug?
|
| Hmmm, this is a little bit of a dark corner in the H98 report, but
there are
| probably other people on this list who know better than me. :-] The
problem
| is that 'realToFrac' is defined as 'fromRational . toRational', so the
first
| question is: How is 'toRational' supposed to handle NaN? One thing
coming to
| my mind is '0 :% 0', but this is normally a value which can't be
constructed.
| So the next question is: Would this be allowed? +Infinity and
-Infinity could
| be represented similarly then ('1 :% 0' and '(-1) :% 0'), and
'fromRational'
| could handle these values specially. But I can't believe that this has
been
| discussed for the first time. SPJ? Malcolm?
|
| When you compile the stuff above with optimizations on, you get what
you've
| expected, thanks to RULES which shortcut the route via Rational
completely.
|
| Cheers,
| S.
|
| ___
| Glasgow-haskell-users mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Double -> CDouble, realToFrac doesn't work
Hal Daume III wrote:
[...]
Prelude Foreign.C> (0 :: CDouble) / 0
NaN
Prelude Foreign.C> (0 :: Double) / 0
NaN
Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble
-Infinity
yikes! the NaN got turned into a -Infinity!!!
aside from manually checking for 'strange' Double/CDouble values and
wrapping realToFrac, is there a better way? also, does this count as a
bug?
Hmmm, this is a little bit of a dark corner in the H98 report, but there are
probably other people on this list who know better than me. :-] The problem
is that 'realToFrac' is defined as 'fromRational . toRational', so the first
question is: How is 'toRational' supposed to handle NaN? One thing coming to
my mind is '0 :% 0', but this is normally a value which can't be constructed.
So the next question is: Would this be allowed? +Infinity and -Infinity could
be represented similarly then ('1 :% 0' and '(-1) :% 0'), and 'fromRational'
could handle these values specially. But I can't believe that this has been
discussed for the first time. SPJ? Malcolm?
When you compile the stuff above with optimizations on, you get what you've
expected, thanks to RULES which shortcut the route via Rational completely.
Cheers,
S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
