[Haskell-cafe] Re: A question about "monad laws"
Richard A. O'Keefe
ok at cs.otago.ac.nz
Thu Feb 14 01:05:32 EST 2008
On 14 Feb 2008, at 6:01 pm, Roman Leshchinskiy wrote:
> I don't understand this. Why use a type which can overflow in the
> first place? Why not use Integer?
Why is this hard to understand?
Dijkstra's classic "A Discipline of Programming" distinguishes
several kinds of machine. I'm quoting from memory here.
A Sufficiently Large Machine is one which can run your program
to completion giving correct answers all the way.
An Insufficiently Large Machine is one which can't do that and
silently goes crazy instead.
A Hopefully Sufficiently Large Machine is one which *either*
does what a Sufficiently Large Machine would have *or* reports
that it couldn't.
The good thing about an SLM is that it always gives you right answers
your program is correct). The bad thing is that you can't afford it.
The good thing about an ILM is that you can afford it. The bad thing
you can't trust it.
The great thing about a HSLM is that you can both trust and afford it.
Presumably the reason for having Int in the language at all is speed.
As people have pointed out several times on this list to my knowledge,
Integer performance is not as good as Int performance, not hardly,
and it is silly to pay that price if I don't actually need it.
The thing about using SafeInt is that I should get the *same* space
from SafeInt as I do from Int, or at the very least the same space
better speed than Integer, while at the same time EITHER the results
results I would have got using Integer *OR* the system promises to
about it, so that I *know* there is a problem.
SafeInt is what you should use when you *THINK* your results should
in a machine int but aren't perfectly sure. (And this is nearly all
Int is what you should use when you don't give a damn what the
results are as
long as you get them fast. (But in that case, why not use C or
>>> You just have to check for exceptional conditions.
>> Why should it be *MY* job to check for exceptional conditions?
> It shouldn't unless you use a type whose contract specifies that
> it's your job to check for them. Which is the case for Int, Float
> and Double.
Wrong. You're confusing two things here. One is Float and Double,
where we get in serious trouble WITHOUT ANY EXCEPTIONAL CONDITIONS IN
The other is Int overflow. There may also be an equivocation on
When was the last time you proved that a large program would not
integer overflow? When was the last time you proved that a library
would not incur integer overflow provided it was called in accord
contract. When was the last time you even *found* a sufficiently
contract in someone else's Haskell code?
The checking I am talking about is done by the hardware at machine
and provides *certainty* that overflow did not occur.
> It's not the case for Integer and Rational.
>> If you think that, you do not understand floating point.
>> x+(y+z) == (x+y)+z fails even though there is nothing exceptional
>> any of the operands or any of the results.
> For all practical purposes, the semantics of (==) is not well
> defined for floating point numbers.
With respect to IEEE arithmetic, wrong.
> That's one of the first things I used to teach my students about
> floats: *never* compare them for equality.
That's one of the warning signs I watch out for. "Never compare
equality" is a sure sign of someone who thinks they know about floats
> So in my view, your example doesn't fail, it's undefined. That
> Haskell provides (==) for floats is unfortunate.
The operation is well defined and required by the IEEE standard.
> If they used (==) for floats, then they simply didn't know what
> they were doing. The fact that a program is commercial doesn't mean
> it's any good.
Er, we weren't talking about (==) for floats; I don't know where you
I never said it was any good; quite the opposite. My point is that
escaped into the commercial market because floating point doesn't
laws people expect it to.
>>> I guess it trapped on creating denormals. But again, presumably
>>> the reason the student used doubles here was because he wanted
>>> his program to be fast. Had he read just a little bit about
>>> floating point, he would have known that it is *not* fast under
>>> certain conditions.
>> Well, no. Close, but no cigar.
>> (a) It wasn't denormals, it was underflow.
> "Creating denormals" and underflow are equivalent.
No they are not. Underflow in this sense occurs when the result is too
small to be even a denormal. (The IEEE exceptions Underflow and Inexact
are not the same. Creating denormals is likely to trigger Inexact but
should not trigger Underflow. I am talking only about a condition that
> Denormals are created as a result of underflow. A denormalised
> number is smaller than any representable normal number. When the
> result of an operation is too small to be represented by a normal
> number, IEEE arithmetic will either trap or return a denormal,
> depending on whether underflow is masked or not.
No, we're talking about a situation where returning a denormal is not
because there is no suitable denormal. This is underflow.
>> (b) The fact underflow was handled by trapping to the operating
>> which then completed the operating by writing a 0.0 to the
>> register, is *NOT* a universal property of floating point, and
>> is *NOT*
>> a universal property of IEEE floating point. It's a fact
>> about that
>> particular architecture, and I happened to have the manual and
>> he didn't.
> IIRC, underflow is a standard IEEE exception.
Underflow is indeed a standard IEEE exception. Like other standard IEEE
exceptions, it is *disabled by default*. In this case, the hardware
delivered the exception *to the operating system*, but the operating
system did not deliver it to the *user code*. It is the *combination*
of hardware and operating system that conforms to the IEEE standard
So we are talking about a situation where the only legal IEEE
"return 0.0" or "raise the Underflow exception" and where raising an
*in the user code* wasn't allowed and didn't happen.
The hardware is allowed to trap to the operating system any time it
like, for any reason (like 'this model doesn't support the SQRTD
or none (hey, it's a Friday, I think I'll generate traps).
The knowledge I had, and the student lacked, was *not* knowledge
interface (the IEEE specification) but about an implementation.
lot of Haskell code out there with no performance guides in the
> I'm not. But progammers I consider competent for this particular
> task know how to use floating point. Your student didn't but that's
> ok for a student.
Wrong. He *did* know "how to use floating point", and his code would
run at the expected speed on other hardware. It gave pretty good
What he didn't know was how one
particular machine struck the balance between hardware and software.
I wonder just how many programmers these days think Double.(*) is
a cheap hardware instruction?
Returning to our theme: the programmer expectation here is "a simple
model." Violating that expectation led to a program with a huge
cost problem. In the same way, violating other programmer
likely to lead to unexpected correctness problems.
More information about the Haskell-Cafe