[Haskell-cafe] Monad laws

[Richard A. O'Keefe]

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

> On Sun, Jun 29, 2014 at 4:28 AM, <ok at cs.otago.ac.nz> 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 = ℵ₀.


>