[boost] Re: Proposal: rational numbers class

From: Lorenzo Gallucci (build_at_[hidden])
Date: 1999-12-07 04:57:22

In stardate Mon, 6 Dec 1999 14:21:07 -0000,  
    Moore, Paul sent a message through subspace...
> From: Kevlin Henney [mailto:Kevlin.Henney_at_[hidden]]
> > I'm not sure that it overcomplicates the implementation
> > in any profound way, or is indeed a misuse of template 
> > parameters. Provide a private member function:
> > 
> >           void dependent_normalize()
> >           {
> >               if(Normalization == normalized)
> >                   normalize();
> >           }
> > 
> > And in each member function that currently calls 
> > normalize(), call dependent_normalize() instead. This
> > would be compiled in at the same cost as before for
> > normalized and at no cost for denormalized.
> The problem is that even with denormalised fractions, you have to normalise
> sometime. Just not after every operation. Deciding when is the big hit. And
> "never" isn't realistic - the user won't know when it is appropriate -
> especially in the face of silently-truncating integer operations. 
I think I can add another point to this...

Even not considering any overflows that could happen, if the code postpones
normalization not only of the magnitudo of numerator and denominator,
but also of their *signs*, this would lead to a more complicated version
of 'operator<'. 
In that case, one would have to consider even the respective signs of
the left and right denominators, and returning the opposite result if
they differ.

That is, the code:
    bool operator< (const rational& r) const
        { return (num * r.den) < (den * r.num); }

would have to be substituted with:
    bool operator< (const rational& r) const
        { return (r.den * den > 0) ? ((num * r.den) < (den * r.num)) :
                ((num * r.den) > (den * r.num)); }

[Test them both with, e.g. 2/(-3) and 1/6, considering that such
fractions could appear at any time without applying normalisation almost on
signs]

Obviously the corresponding overhead could be negligible, depending on
how heavily the user code relies on comparisons, but this also implies
that rational.hpp wouldn't result in a 'quick tool' as intended, I think.

Do you agree?
Thanks!
-------------------------------------------------------------------
\\//_  Live long and prosper and ... HAVE A GOOD TIME! ;-)
Lorenzo Gallucci - wes74_at_[hidden] - ICQ#  19194057
-------------------------------------------------------------------
"There are always chances" -  Spock