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