[Haskell-cafe] Re: A question about "monad laws"

Richard A. O'Keefe ok at cs.otago.ac.nz
Thu Feb 14 22:19:20 EST 2008


On 14 Feb 2008, at 10:24 pm, Roman Leshchinskiy wrote:
> Do I understand correctly that you advocate using overflowing ints  
> (even if they signal overflow) even if Integers are fast enough for  
> a particular program?

No you most certainly do NOT.  There is no way to soundly, and I  
would have
thought no way to plausibly, infer that from anything I wrote.
>

> Again, I strongly disagree. You should use Integer unless your  
> program is too slow and profiling shows that Integer is the  
> culprit. If and only if that is the case should you think about  
> alternatives. That said, I doubt that your SafeInt would be  
> significantly faster than Integer.

SafeInt should be as fast as Int, or very nearly.
The representation of SafeInt is identical to the representation of Int,
so the space overheads are definitely lower.
>> The checking I am talking about is done by the hardware at machine  
>> speeds
>> and provides *certainty* that overflow did not occur.
>
> So you advocate using different hardware?

Again, this is the opposite of what I wrote.
On my desk there are a Pentium machine and an UltraSPARC and a G4.
They *all* support cheap integer overflow checks.
I am saying that we should use the hardware we have already paid for!

> It's not a particularly useful operation (and it is not equality),  
> but it does have a defined semantics. However, the semantics of  
> (==) on floats isn't really defined in Haskell or C, for that  
> matter, even if you know that the hardware is strictly IEEE  
> conformant.

The semantics of == on floats in C99 is, under certain circumstances,  
and on the
machines I use with the compilers I use, defined to be those of the  
IEEE (or,
as the C99 standard puts it, IEC) operation.
>
> In general, floating point numbers do not really have a useful  
> notion of equality. They are approximations.

The *numbers* are not approximations, the *operations* are approximate.
In particular, floating point +, -, *, <, ==, abs, sign, and other  
related
operations (but not /) are *exact* on integral values, if the results  
fit.
AWK programs would be in terrible trouble if this were not so


More information about the Haskell-Cafe mailing list