Looks pretty safe to me.
Historical tidbit... you may wonder how GR is mnemonic for
"base" and POT is mnemonic for "power" as in ((mexpt) GR POT).
It turns out that the macsyma simplifer owes its roots to a
program written by Knut Korsvold in 1963 or so at Stanford University.
It seems that Knut's native language (Norwegian?) has words
for these parts. I don't know what they really are, but
I think they are something like grosse and potenz.
How much is left of Korsvold's simplifier? In terms of
actual code, it is probably a very small percentage. The idea
of hanging the simplification tools on the property lists of
symbols (like MEXPT) was in the original code. Korsvold's
program, called "simplify" I think, also allowed for adding
rules. This was eliminated in the Macsyma version by the
time I saw it in 1968.
I see there is a bug in the bibliographic reference to korsvold
in http://www.cs.berkeley.edu/~fateman/papers/simplifier.txt.
It lists Stanford AI memo #37, but dates it as 1985.
It clearly was not 1985, since that would have required time
travel. Maybe 1965?
RJF
Raymond Toy wrote:
>>>>>>"willisb" == willisb <willisb@unk.edu> writes:
>>>>>
>
> willisb> fixes the float(%e^%e) problem. Have I overlooked something?
> willisb> (I suppose one might try doing something more intelligent when the
> willisb> exponent is a an integer.)
>
>
> willisb> Fixing $FLOAT doesn't fix the %e ^ %e, numer bug.
>
> I think I've found a solution. In simpexpt in simp.lisp, the
> following form fixes the issue:
>
> ((EQ GR '$%E)
> (COND (($BFLOATP POT) (RETURN ($BFLOAT (LIST '(MEXPT) '$%E POT))))
> ((OR (FLOATP POT) (AND $NUMER (INTEGERP POT)))
> (RETURN (EXP (float POT))))
> ((AND $LOGSIMP (AMONG '%LOG POT)) (RETURN (%ETOLOG POT)))
> ((AND $DEMOIVRE (SETQ Z (DEMOIVRE POT))) (RETURN Z))
> ((AND $%EMODE (SETQ Z (%ESPECIAL POT))) (RETURN Z))
> ($numer
> (return ($float (list '(mexpt) '$%e pot))))))
>
> (Look for the lower-case stuff). At this point POT is the exponent.
> For the case where POT is an integer, we weren't converting that to a
> double-float so exp was returning a single-float answer instead of
> double.
>
> The added cond case just says to numerically evaluate the expression.
> Of course, we need your $float fix for this to work. Alternatively,
> without your $float fix, we can do something like
>
> ($numer
> (return ($float (list '(mexpt) '$%e ($float pot)))))
>
> instead. Perhaps this was the intent of the original $float that
> simpexpt handle the given case?
>
> Does this make sense? I think this change is relatively safe for
> inclusion for this release.
>
> Ray
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima