[I thought I already replied to this, but I guess it got lost] Andras Erdei wrote:
On Sun, 6 Mar 2005 20:50:12 -0700, Jonathan Turkanis <technews@kangaroologic.com> wrote:
We might want to allow different rounding policies.
i'll try to write an explanation on why i think there is a single Right rounding method, but it'll take time
This is what I was hinting at here: Jonathan Turkanis wrote:
However, it may be that if we want to avoid sticking all the arithmetic calulations in policy member functions, the only reasonable rounding policy is the one you suggested before. In that case it would just look like
in case you can convince me, or i can't convince you, and we end up with several rounding policies, give a thought to this: rounding is a property of the operations, not the representation,
Agreed.
so one may want + to round upwards and * to round downwards (or this particular + to round up, and the next one to truncate)...
Why would you want that?
Also, we might want assertion failures instead of exceptions.
ok, that's a new variant, then :O)
The "legacy" code doesn't do too well.
i'm not sure how indicative a test with 10000 random numbers is, maybe doing the operations on the results of previous operations would be closer to the real-life scenarios,
True, but I think it would just increase the disparity.
The most obvious signature would be
template< typename Elem, typename Rounding = use_default, typename Checking = use_default > class rational;
[i assume checking would mean reacting by assertion failures, throwing exceptions etc. did i misunderstood?]
Right. I'm borrowing the name "CheckingPolicy" from Andrei Alexandrescu.
theory: rounding (or not), and checking is an either/or: if you do rounding (or ignore the overflows), you have a result, and the operation succeeded, if you fail/thow the operation failed, and no need to bother with rounding the result you can't return
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.
implementation: with assertions and exceptions it seems polite to leave the operands unchanged (so if a *= a fails, you can print the offending a),
but that requires temporaries, maintaining which can seriously degrade performance of the rounding/ignoring code
You're arguing that rational should provide the strong guarantee of exception safety rather than the basic guarantee. If we can verify that providing the strong guarantee does degrade performance, than we shouldn't do it. Or we could make the level of exception safety configurable, but I'd really like to avoid that.
I don't like this. Shouldn't rational<Elem> make sense for any type Elem for which the Euclidean algorithm makes sense?
yes, it should, i was thinking more about what a user wants: "i'm writing an architectural CAD application, and my i/o numbers will be in meters, with millimeter precision, largest value less than a hundred meters, the calculations are this complex, so i want intermediate results with .01mm precision, and volumes at most 1e6 m^3, thus i need rational<1000000>"
it is less obvious why a user would say "i want rational<long>" (also if the user is developing for multiple platforms this one gets ugly)
still, rational<1000,round> will end up triggering a policy to be used, so a hard-line user can still create her own policy to enforce a rational with unsigned char numerator and unsigned long long denominator for her special high-precision calculations with non-negative numbers lessthan 1
I understand what your saying, but I can't tell what template parameters you think rational should have.
I think you can get the effect of restricting the absolute value of the <snip>
[the intent was not bother users with what i feel is implementation details of the representation, but]
i was wondering whether it makes sense to allow restricting the num/den ranges: why would anyone ever deliberately want less precise results than she can get for free? otoh one may want to get the exact same results on a two's complement 32 bit binary machine as on her other, signed decimal architecture, question is whether something like this will ever happen... (if not, always using the native limits may allow some implementation optimizations, don't know yet)
My inclination is to keep everything as simple as possible; we should only add what's clearly missing.
adding an explicit round(num_max,den_max) or round(num_min,num_max,den_max) fn might be a much more useful alternative
This reminds me: perhaps we can borrow some machinery or interface design from numeric_conversion: http://www.boost.org/libs/numeric/conversion/doc/index.html Jonathan