[boost] Re: Proposal: rational numbers class

From: Moore, Paul (Paul.Moore_at_[hidden])
Date: 1999-12-06 04:43:49

From: Andy Sawyer [mailto:boost_at_[hidden]]
> On 03 December 1999 14:34, Paul Moore wrote:
> 
> > 1. Rationals are stored as normalised (numerator, 
> >    denominator) pairs. This has the advantage of
> >    simplicity. I don't see the normalisation cost as
> >    critical, but I'm willing to listen to arguments.
> 
> There are certain situations where not doing the normalisation
> is advantageous (for interests sake, the case I'm thinking of 
> right now is that in some of the American financial markets,
> prices are quoted as fractions. Most options traders aren't
> aware that 8/16 is the same as 1/2 - but then, these are
> people that use numbers like 100.23&16/32...which means
> 100.235. Seriously!)

I'd argue that this counts as a specialised application, and as such a
general-use rational implementation is unlikely ever to be appropriate. A
rational number implemenation might be able to make a distinction between
8/16 and 1/2, but incorporation things like 100.23&16/32 makes this very
definitely into a different "sort" of number..!

>  Of course, the simple fact that there _is_ a cost for 
> normalisation could be seen as an argument against it
> happening automatically. If one wants the normalisation
> to take place, then one can do the normalisation explicitly.
> (Assuming normalise() is made publicly accessible, of course)

I glossed over the fact that conversely, there is a cost to *not*
normalising. The cost then is more complexity in the basic arithmetic
functions like +=. At the moment, += just does an unconditional normalise()
after the addition. With denormalised fractions, you would need to consider
whether any of the sums involved could overflow, before doing them, and if
so, normalise first.

Actually, overflow is not considered in much detail in the current code. But
again, I was more concerned about basic usage and low overhead. My view is
that for this implementation, any fuzzy edges should be documented, not
worked around. Leave complex overflow and numerical issues to more
specialised classes.

As a side point, if a user has a bigint class handy, rational<bigint>
immediately sidesteps all of the overflow/precison style issues. Maybe there
is an argument for a boost implementation (again, I'd argue for a relatively
naive implementation) of a bigint class...

Thanks for the comments,
Paul.