[CLN-list] A silly program

[Richard B. Kreckel]

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/>