It is generally a serious problem to have two representations for the
same thing, and so there are probably
places where sqrt(x) or something similar is entirely bypassed, and
only x^(1/2) is generated.
So a rule that operates only on $sqrt may not be so effective unless the
user actually types in sqrt().
I think this needs more testing, e.g. rat(x^(3/2)) subst (1.2,x,%) ?
Dieter Kaiser wrote:
> I have committed a change to get simplified results for exp(%i*%pi/4).
>
> As reported the expression sqrt(2)/2 is returned as a wrongly simplified
> expression. I have not adjusted the expression like
>
> sqrt(2)/2 --> ((mexpt simp) 2 ((rat simp) -1 2))
>
> but inserted simplifiying code
>
> sqrt(2)/2 --> (div 1 ($sqrt 2))
>
> The simplifying code needs more calls to the simplifier, but I think it is more
> consistent, not to bypass the simplifier. An example is the application of
> rules:
>
> We declare a rule to numerical evaluate sqrt for integers too:
>
> (%i4) matchdeclare(xx,atom)$
> (%i5) tellsimpafter(sqrt(xx),sqrt(float(xx)))$
>
> (%i6) sqrt(2);
> (%o6) 1.414213562373095
>
> But when we return a simplifed expression like ((mexpt simp) 2 ((rat simp) -1
> 2)), the rule does not work:
>
> (%i7) exp(%i*%pi/4);
> (%o7) %i/sqrt(2)+1/sqrt(2)
>
> Now the same with the simplifying code (div 1 ($sqrt 2)):
>
> (%i3) matchdeclare(xx,atom)$
> (%i4) tellsimpafter(sqrt(xx),sqrt(float(xx)))$
>
> sqrt(2) is evaluated numerically, because the simplifier is not bypassed:
>
> (%i6) exp(%i*%pi/4);
> (%o6) 0.70710678118655*%i+0.70710678118655
>
> Perhaps this behavior might be expected by a user, when defining rules.
>
> The global variables sqrt2//2, -sqrt2//2, sqrt3//2, and -sqrt3//2 are no longer
> used. I think we can cut out these variables.
>
> Dieter Kaiser
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>