On 5/11/10, Raymond Toy <toy.raymond at gmail.com> wrote:
> What should maxima do with float(sin(2^2048))? It currently generates
> an error because 2^2048 is too big to fit in a double float.
>
> We could do better than this by doing argument reduction of 2^2048.
>
> Or the easy way is to tell the user to do float(bfloat(sin(2^2048))).
> Should maxima do that automatically?
Well, to have a consistent effect for the float function,
I think the answer is no.
At present float has (or should have; maybe there are already
some special cases) a simple explanation: it changes any
literal numbers or symbolic constants to floats
(and, happily, that's what the reference manual says).
A function which evaluates floats to floats will then yield a
float. E.g. float(sin(1)) is equivalent to sin(float(1)), which
yields a float.
There is a different interpretation of the float function, which
I think I would prefer, namely float(foo(x)) should return the
floating point number closest to the numerical value of foo(x).
Then argument reduction or whatever is necessary would be
applied to sin(giant number) and floating point conversion
later in the game.
The latter is obviously more work, and the former already
entrenched, but both, at least, are easily explained.
I'm pretty sure I'm not in favor of mixing the two.
The former is an approximation to the latter -- maybe we
can claim to adopt the latter and let the existing code stand
as a stop-gap measure.
best,
Robert Dodier