Re: [boost] Re: Re: Re: [rational] Announcing new maintainer -- callforfeature requests

From: Sylvain Pion (Sylvain.Pion_at_[hidden])
Date: 2005-04-08 17:36:46

On Thu, Apr 07, 2005 at 02:49:17PM -0600, Jonathan Turkanis wrote:
> Sylvain Pion wrote:
> > I don't know if it qualifies as real-world, but CGAL (www.cgal.org)
> > provides a Quotient<> class and uses it heavily.
> > It is basically the same thing as boost::rational, although I have
> > not checked the differences in detail, nor tried it.
> > It is used together with big ints or big floats, mostly.
> 
> Since I haven't got many responses from people using boost::rational with finite
> precision types, maybe Quotient<> can help shed light on the question whether
> rational<int> is useless without rounding: do you know whether  Quotient<> is
> ever used with finite precision types, and if so, what is its behavior when the
> result of an operation cannot be expressed exactly?

In the kinds of usages we find in CGAL, I would say that
Quotient with a finite precision number type is useless.
You can use Quotient<int> of course, it will compile, but
I don't see any case where it would be useful.

(I don't have any opinion for other application domains
such as statistical computations for example.)

> > As far as standardization is concerned, I think a big int
> > class should go together with a big rational class
> > (which can benefit from being template).
> 
> Don't you get a "big rational" class for free, as rational<bigint>?

Basically yes, which is why I don't see why bigint should be
standardized without an accompanying way to get a big rational.
I would say that one issue is how simplification between numerator/denominator
is handled.  Various multiprecision rational types I know of and use
(from GMP or LEDA) have different policies, so some user tunability might
definitely be useful here (via policy or via a run time switch or...).  And as
far as customizability wrt the template parameter, I would say that the
simplification routine between numerator and denominator could be the
customization point, so that you do not force gcd or % computation.  (I don't
know how boost::rational handles it, I should look at it in detail.)

-- 
Sylvain