-----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-----