jerzy.karczmarczuk@info.unicaen.fr wrote:
Ben Franksen writes:
jerzy.karczmarczuk@info.unicaen.fr wrote: ...
Does *MATH* answer the question what is: (0/0)==(0/0) ? Nope!
Exactly. So why try to give an answer in Haskell? MATH says: the expression 0/0 is undefined, thus comparing (0/0)==(0/0) is undefined, too. I would expect Haskell to say the same.
I don't know whether you are serious, or you are pulling my leg... Let's suppose that it is serious.
When math says that something is undefined, in my little brain I understand that there is no answer. NO answer.
Oh, come on. You know very well what I am talking about. Defined or undefined is always relative to a set of axioms/laws that we usually take for granted. Division by zero is left undefined (in the sense of 'not defined') for a reason: there is no way to define it without breaking some laws. E.g. A one-point compactification of the real line is a nice thing but it breaks total (global) ordering (and certain algebraic laws, IIRC). I knwo of no mathematical theory that includes a NaN.
Is this the "undefined" you want to have? The bottom non-termination?
In practice, it will be an exception.
Now, this is obviously the *worst* possible reaction of the system, the IEEE indefinite is much better, at least you know what had happened.
It depends. An unsigned Infinity is ok if you are willing to concede that odering is local only and not total. I.e. to every number there is an open interval enclosing it on which the order is total, but it is not (necessarily) total globally. Two (signed) infinities are ok if you are willing to give up more laws.
Would you propose the non-termination as the issue of all "errors", such as negative argument to the real sqrt, etc?
What do you suppose is the answer to head [] ? What makes you think this is a less defined value, compared to, say, 0/0?
Well, as you wish... But don't write medical software, please...
For medical software, somewhere at the end of the calculation there will be some effect to the outside world, if only to display the calculated value. Every pure calculation will eventually be called from the IO monad, where we can catch the exception. What is the advantage of letting the pure calculation continue while it is almost sure that the result will be Nan (=Not a Nan ;) anyway? In the end it won't make a big difference whether the 'undefined' result is due to a (cought) exception or due to a Nan result. I think the exception is cleaner, though. Cheers Ben