On 1/16/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> If you use bfloat on a symbolic expression, it normally converts all
> included numbers into bfloats, e.g.
>
> bfloat(9*(x-2/3)*(x+2/3)) => 9.0b0 (x - 6.6667b-1) (x + 6.6667b-1)
> bfloat(3.4*x) => 3.4b0*x
> bfloat(sin(x+%pi*6/7)) => sin(x + 2.6928b0)
> etc.
>
> But exponents are protected from this if the base is not a number:
>
> bfloat(2^(x+2/3)) => 2.0b0^(x+6.6666667b-1)
> but
> bfloat(q^(x+2/3)) => q^(x+2/3)
> bfloat(q^2.3) => q^2.3
>
> This is presumably to avoid things like
>
> bfloat(x^-1) => x^-1.0b0 (not current behavior)
> bfloat(sqrt(x)) => x^0.5b0 (not current behavior)
> etc.
>
> But it seems as though it would be better to continue to convert all
> *approximate* numbers (not integers and rationals) in the exponent
> since they contain an implicit precision.
Inconsistency of the kind noted above is really one of the weakest
aspects of Maxima. How about if just go ahead and bfloat every
literal number, without exception? If it's really painful to see
bfloat(sqrt(x)) => x^0.5b0 then we could rework bfloat to act on
display representations instead of internal representations or
something like that.
> By the way, the behavior of 'float' is not entirely consistent with
> that of bfloat in cases like this....
Well, we should try to get float and bfloat to act the same.
I know that's easier said than done.
I'm pretty sure there are bug reports in which, for some
values of foo, exp(foo) doesn't yield a number even when numer
and float are true. That kind of stuff is really frustrating, but it
could be resolved pretty simply by cutting out the special cases
for ?mexpt(%e, foo) and other special cases.
For what it's worth,
Robert