On 12 Feb 2008, at 10:35 am, David Benbennick wrote:
Some months ago I pointed out that Ratio Int (which is an Ord
instance) doesn't satisfy this property. I provided a patch to fix
the problem, but my bug report was closed as wontfix:
http://hackage.haskell.org/trac/ghc/ticket/1517.
I'm not happy about that response.
Basically, if the inputs to a mathematical operation are representable,
and the mathematically correct result is representable, I expect a
system
to deliver it or die trying. What the intermediate calculations get up
to is the implementor's problem, not the user's. On the other hand, if
I knew in advance whether a particular + or * was going to overflow, I
probably wouldn't need the computer to actually do it.
But if I give the computer some numbers that are clearly representable
and just ask it to *sort* them, it had better d--- well get that RIGHT.
I am extremely grateful for this report, because now I know
"NEVER USE Ratio Int, it's too broken".
Sad aside: back in the 70s I had my own Ratio Int written in Burroughs
Algol. I was not smart enough to use double precision numbers for
anything,
but because of one hardware feature, it didn't matter a lot. That
hardware
feature was that integer overflows were TRAPPED and REPORTED. I have
since
used precisely one C compiler on precisely one Unix system that took
advantage
of the fact that the C standard (both C89 and C99) was very carefully
written
to ALLOW TRAPPING of signed integer overflows. (Contrary to
mythology, C
only requires wrapping for unsigned integers.) I found that a
surprisingly
valuable debugging aid.
This all supports the general point, of course: data types whose
operations
are so implemented as to break sensible laws can and WILL land you in
great
piles of fresh steaming hot fertiliser.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
