Re: Double -> CDouble, realToFrac doesn't work
[switching to libraries] Recap: the definition of realToFrac as going through Rational loses the NaN and +/-Infinity values of Double and Float (though GHC's RULES bypass this). 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?
[The proposal is to add 0:%0, 1:%0 and -1:%0 to Rational.] Changing Rational from meaning rational numbers would also be bad. I'd prefer to redefine realToFrac to go through a new type that is the union of Rational and these values. That would mean adding extended variants of toRational and fromRational to the Real and Fractional classes, with default definitions but overidden for the Float and Double instances. This type and the variant of fromRational might be usable for floating point literals too.
Printing those values could be more consistent for these systems, too, BTW.
True, though Hugs is already inconsistent with H98 in its printing of floating point values.
ross@soi.city.ac.uk writes:
[The proposal is to add 0:%0, 1:%0 and -1:%0 to Rational.]
Changing Rational from meaning rational numbers would also be bad. I'd prefer to redefine realToFrac to go through a new type that is the union of Rational and these values.
It's not enough if you care about preserving -0.0. Instead of materializing variants, the function could check isInfinite etc. - except that these functions are in RealFloat class, not available for arbitrary Real numbers. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
On Fri, Nov 05, 2004 at 10:53:36AM +0100, Marcin 'Qrczak' Kowalczyk wrote:
ross@soi.city.ac.uk writes:
[The proposal is to add 0:%0, 1:%0 and -1:%0 to Rational.]
Changing Rational from meaning rational numbers would also be bad. I'd prefer to redefine realToFrac to go through a new type that is the union of Rational and these values.
It's not enough if you care about preserving -0.0.
True, and denormalized values (whatever they are).
Instead of materializing variants, the function could check isInfinite etc. - except that these functions are in RealFloat class, not available for arbitrary Real numbers.
But isn't that fatal? We're stuck with the type realToFrac :: (Real a, Fractional b) => a -> b All we can change is its specification.
On Fri, Nov 05, 2004 at 10:53:36AM +0100, Marcin 'Qrczak' Kowalczyk wrote:
ross@soi.city.ac.uk writes:
[The proposal is to add 0:%0, 1:%0 and -1:%0 to Rational.]
Changing Rational from meaning rational numbers would also be bad. I'd prefer to redefine realToFrac to go through a new type that is the union of Rational and these values.
It's not enough if you care about preserving -0.0.
True, and denormalized values (whatever they are).
Denorms are handled fine by ordinary Rationals, but collapsing all NaNs
down to 0:%0 is not necessarily the right thing to do.
Surely we should add another fractional type, like Rational but with some extra stuff to make it a superset of Double.
--KW 8-)
--
Keith Wansbrough
On Fri, 5 Nov 2004, Keith Wansbrough wrote:
On Fri, Nov 05, 2004 at 10:53:36AM +0100, Marcin 'Qrczak' Kowalczyk wrote:
ross@soi.city.ac.uk writes:
[The proposal is to add 0:%0, 1:%0 and -1:%0 to Rational.]
Changing Rational from meaning rational numbers would also be bad. I'd prefer to redefine realToFrac to go through a new type that is the union of Rational and these values.
It's not enough if you care about preserving -0.0.
True, and denormalized values (whatever they are).
Denorms are handled fine by ordinary Rationals, but collapsing all NaNs down to 0:%0 is not necessarily the right thing to do.
Yep. Given a % b == c % d iff a*d == b*c then 0 % 0 is equivalent to each other rational. :-)
Surely we should add another fractional type, like Rational but with some extra stuff to make it a superset of Double.
One could define 2x2 types: {finit, infinit} x {rational, float} Every type containing infinity misses some fundamental mathematical properties, like a natural order and closedness with respect to (+), (-), (*), whereas the types including infinity may be of more interest for numerical applications.
Denorms are handled fine by ordinary Rationals, but collapsing all NaNs down to 0:%0 is not necessarily the right thing to do.
Yep. Given a % b == c % d iff a*d == b*c
then 0 % 0 is equivalent to each other rational. :-)
Ah! Not very good. But that wasn't what I meant. There's not just *one* NaN - there are 2^53 - 2 distinct ones. In fact they all get treated identically, but the bit-patterns are distinct. --KW 8-)
On Fri, 5 Nov 2004, Ross Paterson wrote:
On Fri, Nov 05, 2004 at 10:53:36AM +0100, Marcin 'Qrczak' Kowalczyk wrote:
ross@soi.city.ac.uk writes:
[The proposal is to add 0:%0, 1:%0 and -1:%0 to Rational.]
Changing Rational from meaning rational numbers would also be bad. I'd prefer to redefine realToFrac to go through a new type that is the union of Rational and these values.
It's not enough if you care about preserving -0.0.
True, and denormalized values (whatever they are).
Denormalized numbers are not really special, they are just there to fill the gap between the smallest normalized number and 0. If there were only normalized numbers, we could only represent the numbers 0, 1.000000 * 10^-e, 1.000001 * 10^-e, 1.000010 * 10^-e, ... (everything binary) As you can see the gap from 0 to 1.000000 * 10^-e is much larger than that from 1.000000 * 10^-e to 1.000001 * 10^-e, that's why unnormalized numbers like 0.111111 * 10^-e are inserted. They are common numbers in an uncommon representation. In practice if you encounter them you have made something wrong, because they are so close to zero ...
On Fri, 5 Nov 2004 ross@soi.city.ac.uk wrote:
Printing those values could be more consistent for these systems, too, BTW.
True, though Hugs is already inconsistent with H98 in its printing of floating point values.
Good to know that, I always thought the differences in output would be due to implementation freedom. I had problems with comparing results from GHC and Hugs.
On Fri, Nov 05, 2004 at 12:20:01AM +0000, ross@soi.city.ac.uk wrote:
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?
[The proposal is to add 0:%0, 1:%0 and -1:%0 to Rational.]
I see that GHC has had this for a while, to handle reading floats: http://www.haskell.org//pipermail/cvs-libraries/2002-June/000231.html NHC solves that one by redefining read to bypass Rational on "NaN" and "Infinity". The NHC solution seems reasonable for read, but I still think a new type would be better for realToFrac. Hugs in CVS throws ArithException Overflow if any of the extra values are fed to toRational or decodeFloat. (Released Hugs has a bizarre bug there.)
ross@soi.city.ac.uk wrote:
[...] True, though Hugs is already inconsistent with H98 in its printing of floating point values.
This is not quite right: Numeric.showFloat would be OK (modulo "arithmetic overflow" :-), but Hugs currently uses C's snprintf, resulting in "inf"/"nan", not "Infinity"/"NaN" on my SuSE 9.1 box. Cheers, S.
participants (6)
-
Henning Thielemann -
Keith Wansbrough -
Marcin 'Qrczak' Kowalczyk -
Ross Paterson -
ross＠soi.city.ac.uk
-
Sven Panne