For what it is worth, in commercial macsyma,
float(exp(2)) returns %e^2. To get a number, you need to do
ev(%,numer), in which
case you get single precision.
dfloat(%e^2) gives 7.3890560983064d0
and
bfloat(%e^2) gives more digits.
this seems to me to be inconsistent behavior. I've never really liked
the macsyma
behavior where you attempt to get a numeric result but it insists on
leaving constants
like %e around.
I think there is little need for single-precision floats in maxima,
but I suppose I can tolerate them as long as they don't get in anyone's
way.
RJF
Raymond Toy wrote:
>Bug 617021 is about bfloat(%gamma) not returning a bigfloat result.
>There is a fix for this in
>http://www.math.utexas.edu/pipermail/maxima/2002/002876.html, which
>I'd like to check in. Any objections?
>
>Bug 586688 is about float(exp(2)) returning 7.389056, a single-float result
>instead of a double-float result.
>
>I've attached a patch that fixes this. It seems to be a bug in
>exptb. It computes a^b when b is an integer. When a = %e, it uses
>(exp b), which is a single-float result, not double.
>
>Ray
>
>
>+;; I (rtoy) think EXPTB is meant to compute a^b, where b is an
>+;; integer.
> (defun exptb (a b)
>- (cond ((equal a %e-val) (exp b))
>- ((or (floatp a) (not (minusp b))) (expt a b))
>- (t (setq b (expt a (minus b))) (*red 1 b))))
>+ (cond ((equal a %e-val)
>+ ;; Make B a float so we'll get double-precision result.
>+ (exp (float b)))
>+ ((or (floatp a) (not (minusp b)))
>+ ;; We convert b to float just in case so we get a
>+ ;; double-precision result. (It seems that a is never a
>+ ;; single-float, so floating-point contagion will make sure
>+ ;; the result is a double, but let's be sure.)
>+ (expt a (float b)))
>+ (t
>+ (setq b (expt a (minus b)))
>+ (*red 1 b))))
>
>_______________________________________________
>Maxima mailing list
>Maxima@www.math.utexas.edu
>http://www.math.utexas.edu/mailman/listinfo/maxima
>
>