Hi! Before anybody protests: I solemnly promise not to even try to to think again when I'm tired! On Wed, 24 Nov 2004, Richard B. Kreckel wrote: [...]
First, you dodged the question of the return type. What should cln::operator@(float, const cln::cl_R&) return? Is it just to conveniently save a few keystrokes and should hence return a cln::cl_R? No, wait! cln::cl_R can have arbitrary precision but we do know the resulting precision cannot be better than that of float or double, respectively. It would be wrong to return anything other than cl_FF or cl_DF; why return a base type? Okay, that'ld leave us with implementing:
inline const cl_FF operator@ (const cl_R& x, const float y) { return float_approx(x) @ y; } inline const cl_FF operator@ (const float x, const cl_R& y) { return x @ float_approx(y); }
and the same for double. And possibly for cl_F due to efficiency concerns.
The above line of reasoning is entirely wrong. In CLN's type scheme, the return value of operator@ (const cl_F&, float) must be cl_F and not cl_FF. This is because the cl_F argument could actually have been a cl_SF. Then, a cl_SF is returned, which is derived from cl_F, but *not* from cl_FF.
In any case, that operator@ can hardly be said to be an operation in cl_R any more, because it always reduces its arguments precision-wise and does so even by declaration!
Even though that wasn't meant as a mathematically rigorous statement in the first place and even though it might not be technically wrong, it is pointless.
This is why I am reluctant about such operators. If a user wants his nice 1000 digit precision computation to decay he should be forced to state so explicitly.
Still a valid objection. But probably a moot one. No, I haven't been abusing drugs yesterday. Maybe I should have. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>