Dieter,
There is no change of the assumption that variables in Maxima are assumed to
> be real.
Agreed.
> What has changed is that it is not assumed that variables in Maxima have a
> positive real value.
>
That is one way of looking at it. The other way of looking at it is that
previously Maxima assumed that *expressions* were real. If you assume that
sqrt(1/x) is real, then sqrt(1/x)=1/sqrt(x).
Real analysis considers x<0 to be outside the domain of sqrt(1/x); sqrt(1/x)
is simply undefined for x<0. Old Maxima was a bit more permissive than true
real analysis. It manipulated sqrt(1/x) *as though* it was a function of the
non-negative reals to the reals, but if you substituted -1 for x, it would
still carry through the operation, not give an error.
One could imagine handling all this in other ways as well. Maxima could
always ask the user whether it could assume that x>0 when simplifying
sqrt(1/x); it could assume that x>0 without notifying the user, but attach a
"caveat" to the result of simplifications like sqrt(1/x) => 1/sqrt(x); it
could return a conditional expression like "if realp(x) and x>0 then
1/sqrt(x) else sqrt(1/x); etc. The first and third solutions are, I think
we'd all agree, too clumsy. The second is a possibility, but would require
changes to many parts of Maxima.
> The rule not to simplify sqrt(1/x) in general for a real
> variable x is consistent with Maximas rules for the simplification of
> negative integers (the simplification to the principal value is
> implemented):
>
Well, yes, the principal value is well-defined for numbers. But trying to
preserve principal value in symbolic calculations on symbolic expressions is
more difficult -- and perhaps not even a good idea. It might be a better
idea to treat complex functions as defined on Riemann surfaces.
One of the main problems in older versions of Maxima was, that there was no
> way to switch off the simplification of expressions like sqrt(1/x)
> or log(1/x).
>
In a fist step I would like to suggest the following approach. The
> standard values of the option variables can be:
>
> domain: real
> radexpand: true
> logexpand: true
>
I agree with this proposal.
Any of the following settings switches off the default simplifications:
>
> domain: complex
> radexpand: false (only sqrt(1/x) is switched off)
> logexpand: false (only log(1/x) is switched off)
>
Agreed.
> To get this behavior some changes have to be reverted and the option
> variable domain has to be implemented more completely.
>
Yes, agreed.
> (%i1) (-2.0)^(1/2);
> (%o1) 1.414213562373095*%i
>
> (%i2) (-2.0)^(0.5);
> (%o2) (-2.0)^0.5
>
> (%i3) (-2.0)^(0.5),numer_pbranch:true;
> (%o3) 1.414213562373095*%i+8.659274570719356e-17
Yes. Even worse, consider (-1)^(1/3) => -1 vs.
rectform((-1.0)^(0.33333333333333)) => .5 + .9*%i .
Over the reals, we would like (-1)^(1/q) => -1 for odd integer q; but what
should it be for real or float q? Floats are approximations (though they're
expressed as fractions p*2^n), so it's not useful to ask whether their
denominator is odd....
-s