On Tue, Mar 20, 2007 at 03:53:58PM +0000, Malcolm Wallace wrote:

Ian Lynagh wrote:

...

(D# x) `compare` (D# y) | x <## y = LT | x ==## y = EQ | otherwise = GT

becomes

(D# x) `compare` (D# y) | x <## y = LT | x ==## y = EQ | x >## y = GT | otherwise = error "Incomparable values"

I'm pretty uncomfortable with calling 'error' in this situation. How about throwing an imprecise exception instead?

Doesn't error throw an imprecise exception? We already have things like remInteger ia ib | ib == 0 = error "Prelude.Integral.rem{Integer}: divide by 0" We could throw (ArithException something) instead if that's what you mean, but I think we'd need a new constructor for something. I'm not sure if it should be an ArithException or not. (should remInteger above throw (ArithException DivideByZero)? We'd give a less useful message to the developer, but have something possibly more useful to catch. I've wished for exceptions to have a stack of locations in the past; perhaps that should be another proposal.) Thanks Ian

Hi

...

Neither of these is very satisfactory, as I would expect [...]

And _|_ is perhaps the least satisfactory value of them all! Following on from the tradition of ByteString, will it be acceptable for the compiler to turn _|_ into False, as an optimisation? I agree very much with Sven here, nothing as simple as comparison or equality should make a program crash. I wouldn't mind division by zero raising an error - that is something that you could argue for. Given that Ord and Num operations on Double/Float don't obey lots of useful properties, due to rounding, perhaps we should just make it clear (somewhere) that floating point numbers aren't nice things to work with, and should be avoided when an Integer will do fine. Maybe thats already implicit in most programmers heads though, so doesn't even need stating. Thanks Neil

On Wed, Mar 21, 2007 at 06:58:46PM +0000, David House wrote:

On 21/03/07, Neil Mitchell wrote:

...

Following on from the tradition of ByteString, will it be acceptable for the compiler to turn _|_ into False, as an optimisation?

My interpretation of Ian's message was a questioning of the behaviour of compare, not of (<) etc. compare can't return False.

Right, I'm happy with the three False's, it's the incompatible result of compare that I'm objecting to. As Sven thinks the real solution is to modify the report such that this case can be handled nicely without raising an exception, I've closed the proposal and opened a Haskell' ticket for it. Thus we can discuss what the answer should be for Haskell' and change the report or not as we think appropriate, before finally fixing the problem. http://hackage.haskell.org/trac/haskell-prime/ticket/123

...

I agree very much with Sven here, nothing as simple as comparison or equality should make a program crash. I wouldn't mind division by zero raising an error - that is something that you could argue for.

Doesn't compare need to force its arguments anyway, so that (0/0) `compare` (0/0) would be a divide-by-zero error?

Not with Float and Double: Prelude> 0/0 :: Double NaN Prelude> 0/0 :: Float NaN Thanks Ian

I'm still not happy with adding more incompleteness into something that intuitively feels safe - compare is pretty benign. Having a crash on division is something that does appeal to me more. Are you suggesting that 0.0/0.0 should crash also? I'm no expert, but

Neil Mitchell wrote: think returning a NaN is according to the floating point standard (IEEE 754), and I'm not convinced Haskell should break that. If you use floating point, you need to know the pitfalls anyway. Maybe comparing NaNs should give random results? :-) The bad thing is that comparison can hide the NaNs (for arithmetic, NaNs will be contagious, so you'll likely get a NaN riddled output). One thing I remember seeing (from Fortran compilers?) is that when a program execution involves a NaN, it is reported on termination, even if the NaN was in an intermediate calculation and not part of the final result. Something like that could perhaps be useful if the current behavior is kept? -k

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ketil Malde wrote:

...

I'm still not happy with adding more incompleteness into something that intuitively feels safe - compare is pretty benign. Having a crash on division is something that does appeal to me more. Are you suggesting that 0.0/0.0 should crash also? I'm no expert, but

Neil Mitchell wrote: think returning a NaN is according to the floating point standard (IEEE 754), and I'm not convinced Haskell should break that. If you use floating point, you need to know the pitfalls anyway. Maybe comparing NaNs should give random results? :-)

:-) non-referential-transparency always seems attractive for silly cases like this, doesn't it

The bad thing is that comparison can hide the NaNs (for arithmetic, NaNs will be contagious, so you'll likely get a NaN riddled output).

Yes - non-signalling NaN in a pure language like Haskell is similar to _|_, with the biggest difference being that you can check whether a value is NaN/Inf/-Inf (in pure code). (where that _|_ could specifically be some sort of NaN imprecise exception). Of course _|_ is still the least fixed point, e.g. infinity = infinity + 1 won't give you an Infinity. So, do we want _some_ computations to be ill-defined in a well-behaved way by using the IEEE NaN bit-patterns as we do? The FiniteDouble wrapper seem like an interesting approach. If you don't want the CPU to do all that checking of intermediate values... but that can be optimized away anyway. What is a use case for code that wants to check whether a value is NaN? Perhaps the positive and negative infinities are more commonly worth being non-_|_ since they don't break the total order and can be generated by mere overflow (2.0^(2^1000) anyone?). Furthermore, since with a large finite double subtracting 1 does not reduce the number, is infinity that much weirder? Another approach I tried with a type for integers including +-Infinity and NaN was to just arbitrarily make NaN be less than all other values, including -Infinity, and it is a total order (other values are greater than NaN, and NaN is equal to itself). That way it can be stored in Maps and such. (I later decided I didn't really like the mathematically not-very-sensible-ness of those values existing, for my use case, but that's a different matter.) Does anyone else think (==) should always be reflexive for any type it's defined for? (i.e. for all n, (n==n)==True) (except when its arguments contain _|_, in which case (==) might inevitably result in _|_). The class "RealFloat" in the prelude already provides isNaN, isInfinite... which are more sensible than checking for NaN with not(n==n) in Haskell Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBSbdHgcxvIWYTTURAu1RAJ44waLiwdfIklbUmFyXW1CwVI2CEwCgzRBF 4wU29F5OIKCdWyK41crSX3s= =usWc -----END PGP SIGNATURE-----

Hi

Note that in the bytestring case the compiler doesn't do so, it's the library that does (by telling the compiler to rewrite things with RULEs).

ByteString is in base, and ships with GHC, I think that makes it GHC's fault if it does naughty things.

Unfortunately, it's very appealing in bytestring's case...

Yes, the dilema between performance and purity...

...

For reference, my Catch tool treats Float/Double compare as never crashing, and division by zero as always crashing

Even for Double/Float?

Yes.

There's also:

Prelude> (minBound :: Int) `div` (-1) *** Exception: arithmetic overflow

but you probably can't do much about that in Catch.

There is an easy solution, always use Integers. Catch also assumes rules like adding two positive numbers results in a positive number - which unfortunately isn't actually true. Thanks Neil