Re: [Haskell-cafe] Monad laws

On 29/06/2014, at 9:53 PM, Mike Meyer wrote:

On Sun, Jun 29, 2014 at 4:28 AM, wrote: On the subject of Double and laws, I imagine it would have been possible to do the kind of thing the SML Basis Library does for equality. SML spells equality '=' and it's not defined on the floating point types, which have a *different* operator, '=='.

If you do that, where do you stop?

Well, SML stopped right there.

Not all Int's have additive inverses, and most floats have multiple things they can be added to that don't change their value. Can we call both of those +? Or do we need a name for them or two?

For what it's worth, O'CAML *does* have separate operators for integer addition and floating-point addition.

Actually, I don't know if SML got it right or not, because I don't know what the "==" operator does.

It's really very easy to find on the web. val == real * real -> bool val != real * real -> bool val ?= real * real -> bool [x == y] returns true if and only if neither x nor y is a NaN and x and y are equal, ignoring signs on zeros. This function is equivalent to the IEEE = operator. The second function != is equivalent to (not o op ==) and the IEEE ?<> operator. [?=] returns true if and only if either argument is a NaN or the arguments are bitwise equal, ignoring signs on zeros. It is equivalent to the IEEE ?= operator.

But you should *never* compare floats for equality.

You are mistaken.

While there are exceptions, they are so rare that you're likely never to run into one, so just be safe, and don't do it.

I have in fact *often* run into the so-called exceptions. Indeed, anyone using Javascript and wanting to compare two "integers" will in fact be comparing floating point numbers and they will be fully justified in doing so.

So if SML's "==" operator is an equality comparison, they at best got it half right.

It depends on what you want to call 'an equality comparison'. It is one of the comparison operators specified in the IEEE standard. There is no fuzziness or ambiguity about its semantics. They COULDN'T leave it out and claim IEEE conformance.

If it's some kind of programmer-controlled "fuzzy equality", well, maybe. But I think just leaving it out would be a better solution.

I have seldom seen any kind of programmer-controlled "fuzzy equality" that wasn't either dangerously wrong or dangerously misapplied, and I speak as an old APLer who knows what ⌷CT stands for, where to find it in the standard, and why it is risky. If you leave out ==, some irritated programmer will just define fun ==(x, y) = x >= y andalso x <= y and you're back where you started. To prevent anyone doing that, you have to leave out *ALL* the floating-point comparison operators. That is not sensible.

Is x == x being false really any more surprising than x + 1 == x being true?

Yes. The idea of there being a "number" x such that x + 1 == x is familiar to anyone who has ever met the extended real line. Or who knows that ℵ₀ + 1 = ℵ₀.