Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-10 11:37:52

Andras Erdei wrote:
> On Mon, 7 Mar 2005 17:50:48 -0700, Jonathan Turkanis
> <technews_at_[hidden]> wrote:
>> I can't tell what template parameters you think rational should have.
> (it is because i don't know myself :O)


> i think we need two parameters: one for specifying the precision,
> and one for specifying the variant to use

But this leaves out the int_type; users must be able to write


or similarly for any UDT which supports the euclidean algorithm.

> the problems:
> 1. if we specify the precision as an integer, e.g. rational<1000>
> meaning a rational with numerator range (-1000,1000) and denominator
> range (1,1000),
> then we restrict the possible underlying types to the
> integer type used as the template parameter (and smaller)
> a possible workaround is to specify the log of the limits instead, so
> e.g. rational<31> would mean (-2^31,2^31) and (1,2^31) -- this is
> less flexible, than the above one, but i can't come up with anything
> better

I believe precision should be specified by supplying an appropriate type as the
int type, e.g., restricted_int<1000>.

> 2. i don't know how can we implement the selection of UDTs: let's say
> i have implemented a modular arithmetic bigint type, with up to a few
> hundred bits of precision -- how can i tell rational that it can
> select this as the underlying type?

It has to be specified as a template parameter. Even if we specified a whole
range of types, including big_int, to serve as the underlying type depending on
the specified precision, an arbitrary user-supplied type would never be

> <snip>
>> The above declaration was based on the assumption that multiple
>> rounding policies should be supported. If there's only one way to
>> round, then rounding can be merged into the checking policy.
> i don't see how this depends on having more than one kind of rounding:
> either you round, or you check, cannot do both at the same time -- do
> i miss something?

Okay, I see. The various checking policies, such as assert_check, etc., are just
rounding policies which alert the used that something has gone wrong as soon as
it is determined that rounding is required. Good. So rational should look like:

  template<typename Elem, typename Rounding = use_default>
  class rational;

On top of this could be built a restricted precision rational class.


Boost list run by bdawes at, gregod at, cpdaniel at, john at