[Haskell-cafe] 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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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! ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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 Javas 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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Double - CDouble, realToFrac doesn't work
On Friday 05 November 2004 14:57, Henning Thielemann wrote: On Fri, 5 Nov 2004, Robert Dockins wrote: I wonder why Infinity has a sign in IEEE floating processing, as well as 0. As regards Inf, this makes sense, because with +Inf and -Inf order is preserved. With one unsigned Inf nothing is really or than anything else. 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's worse: Since according to IEEE +0 is not equal to -0, atan2 is not a function! Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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. .. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Double - CDouble, realToFrac doesn't work
On Friday 05 November 2004 14:11, you wrote: It's worse: Since according to IEEE +0 is not equal to -0, atan2 is not a function! Sorry, I meant to write: Since according to IEEE +0 *is* to be regarded as equal to -0, atan2 is not a function. (Because it gives different values for argument combinations -0, +0.) Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Double - CDouble, realToFrac doesn't work
Benjamin Franksen [EMAIL PROTECTED] writes: It's worse: Since according to IEEE +0 is not equal to -0, atan2 is not a function! Sorry, I meant to write: Since according to IEEE +0 *is* to be regarded as equal to -0, atan2 is not a function. (Because it gives different values for argument combinations -0, +0.) From my point of view it is a function. Only == is not the finest equality possible (but the one which is more useful). -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
