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
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
>> 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>
On top of this could be built a restricted precision rational class.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk