Jonathan Turkanis wrote:
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
rational<big_int>
or similarly for any UDT which supports the euclidean algorithm.
[personally i don't like the name big_int, i always have to translate it mentally from meaning "arbitrary/big, but limited precision" like a modular arithmetic based integer type, to "unlimited (dynamic) precision"] i'm not entirely convinced that the unlimited precision rational should be treated (at the interface level) as a special case of the fixed precision rational type: rounding/checking does not make sense with it, it may turn out to require a (sadly) slightly different interface (e.g. it may be better off with allowing expression templates to be used -- although that could be true for limited precision as well), and the implementation will surely not share code with that of limited precision keeping it separate may also solve our backward compatyibility problem (having no rounding by default): if rational<> is kept for unlimited (but allow instantiation with any type), then we'll still have the legacy behaviour, and we can choose a new name for limited rational, e.g. rational being an alias for unlimited::rational, and having separate limited::rational and unlimited::rational
I believe precision should be specified by supplying an appropriate type as the int type, e.g., restricted_int<1000>.
the point of specifying the limit would be to free the user from having to portably figure out which is the fastest type on the given platform whose precision exceeds the limit given (not having to specify a type at all)
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 selected.
i was hoping for some solution that e.g. allows UDTs to be somehow registered (at compile time) and then selected by rational automagically, but again, i'm not sure it is good what i hope for -- maybe it's simpler and more natural to say rational<modular> than register(modular) and then rational<128>
On top of this could be built a restricted precision rational class.
if you mean rational<10000,round> will translate to something like rational<int,int,...,round>, and the latter would also be directly available to users who need it, then of course, i just wouldn't make it the top-level interface, rather something for advanced users who know what they are doing br, andras