Overflow in Ratio

haskell at list.mightyreason.com haskell at list.mightyreason.com
Sun Jul 22 09:14:44 EDT 2007

I am going to take a guess and say that the library policy is that (Num Integer) 
  and (Ratio Integer) are known to follow the axioms, but anyone who uses (Num 
Int) and (Ratio Int) did so to get the size and performance and does not want to 
cast to Integer.

Just as someone who uses (Word8) really wants to conserve space, much as the 
Array of Bool is usually implemented as bitpacked in memory.

David Benbennick wrote:
> The Ratio data type suffers from numeric overflow.  For example,
> consider the Ord declaration in the Haskell 98 Report (I'm looking at
> page 153, section 12.1 of
> http://haskell.org/definition/haskell98-report.pdf):
>    (x:%y) <= (x':%y')  =  x * y' <= x' * y
> It is easy to see that Ratio Int is not well-ordered under this
> definition, because of overflow.  This is a self-contradiction in the
> Report, since page 84 (section 6.3.2) says that "The Ord class is used
> for totally ordered datatypes".
> I think the best way to resolve this contradiction is to avoid
> overflow.  For example, the following definition works:
>    (x:%y) <= (x':%y')  =  (toInteger x) * (toInteger y') <=
> (toInteger x') * (toInteger y)
> I submitted a complete patch at
> http://hackage.haskell.org/trac/ghc/ticket/1517, but that was
> apparently the wrong place, since the bug was closed as wontfix.
> Is there a chance of getting this contradiction resolved?  I'll be
> happy to provide unit tests for the change if that will help get it
> applied.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

More information about the Libraries mailing list