[boost] Re: Proposal: rational numbers class

From: Moore, Paul (Paul.Moore_at_[hidden])
Date: 1999-12-06 08:27:09

From: Kevlin Henney [mailto:Kevlin.Henney_at_[hidden]]
> 
> It seems that there is a case to be made both for and against 
> automatic normalisation.

To be honest, I haven't seen much of a case yet for denormalisation. No-one
has come up with a good example of where the intended users of the class
(note: this is a proper subset of all people who might need some form of
rational numbers) would want to see denormalised fractions exposed. And
internally, the cost of normalisation is not high - and the cost of leaving
fractions denormalised is pretty similar.

> Looking at it from a quality of service point of view, there
> is a case to be made for accommodating both. This could be 
> done either at runtime

Yuk, no. rational<>, like complex<>, should be as fast as possible.

> or, preferably, at compile time, with the default -- 
> looking at the responses on the list so far -- being to always
> normalise:

To be honest, there hasn't been much strong feeling either way (except from
me, and I want the easiest to implement :-)

>    template<typename Int, bool normalize = true>
>    class rational
>    {
>        ...
>    };

The difficulty with this is two-fold. First (a minor one),
rational<int,false> doesn't seem to me to be an intuitive way of getting
denormatised fractions of ints. The more important issue is that we simply
have two largely disjoint implementations (the guts of the implementation is
so small that it would be hard for *any* implementation variation not to
affect everything!), and triggering the distinction via a template parameter
seems (to me) to be using templates inappropriately. What's wrong with
denormalised_rational<int>? Or just making a decision on behalf of the user?
The standard library doesn't provide every possible implementation strategy
for map<> or set<> or list<>... For that matter, std::complex<> doesn't let
you choose whether or not you want polar or cartesian representation.

Paul.

Paul.