Am Montag, den 25.07.2011, 12:06 -0400 schrieb Stavros Macrakis:
> A bunch of defaults in recent Maximas (changed a year ago or so)
> appear to have changed from assuming that variables and expressions
> are real-valued by default to assuming that they are complex-valued by
> default.
>
>
> For example, log(1/x) no longer simplifies to -log(x) and sqrt(1/x) no
> longer simplifies to 1/sqrt(x).
>
>
> I understand that these simplifications do not treat branch cuts
> consistently in the complex plane. However, Maxima made the design
> decision a long time ago that by default, entities (both undeclared
> variables and values) were assumed to be real. This design decision
> is still reflected by much of Maxima; thus sign(sqrt(x)) => pz,
> sign(log(x)) => pnz. In general, it is *not* true in Maxima that
> substituting a complex value for a variable will give reasonable
> results. For example, subst(%i,x,rectform(log(x))) yielsd %i*atan2(0,
> %i), which Maxima can't simplify any further as far as I can tell --
> because atan2 is assumed to have real arguments.
>
>
> Moreover, even in the complex plane, as far as I know, no one has come
> up with a consistent, correct, and useful way of handling either
> branch-cut semantics or Riemann-surface semantics in Maxima.
>
>
>
> The main effects of suppressing simplifications log(1/x) => -log(x)
> appear to be
>
>
> (1) confusing new users (and some old users)
> and
> (2) breaking existing code (in particular integration)
>
>
> I propose we return to the "everything is real" assumption as the
> default in Maxima.
>
>
> Discussion?
There is no change of the assumption that variables in Maxima are
assumed to be real. What has changed is that it is not assumed that
variables in Maxima have a positive real value.
x is assumed to be a real variable:
(%i1) sqrt(1/x);
1
(%o1) sqrt(-)
x
(%i2) log(1/x);
1
(%o2) log(-)
x
a is assumed to be a positive real variable:
(%i3) assume(a>0);
(%o3) [a > 0]
(%i4) sqrt(1/a);
1
(%o4) -------
sqrt(a)
(%i5) log(1/a);
(%o5) - log(a)
For example: 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):
(%i1) sqrt(-1/2);
(%o1) %i/sqrt(2)
(%i2) sqrt(-2);
(%o2) sqrt(2)*%i
(%i3) expr1: sqrt(1/x)-1/sqrt(x)$
(%i4) subst(x=2, expr1),ratsimp;
(%o4) 0
(%i5) subst(x=-2, expr1),ratsimp;
(%o5) sqrt(2)*%i
(%i6) expr2: sqrt(1/x)+1/sqrt(x)$
(%i7) subst(x=2, expr2),ratsimp;
(%o7) sqrt(2)
(%i8) subst(x=-2, expr2),ratsimp;
(%o8) 0
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).
Maxima version: 5.10.0
Maxima build date: 21:56 3/14/2011
host type: i686-pc-linux-gnu
lisp-implementation-type: SBCL
lisp-implementation-version: 1.0.45
(%i1) domain:complex;
(%o1) complex
(%i2) sqrt(1/x);
(%o2) 1/sqrt(x)
(%i3) log(1/x);
(%o3) -log(x)
(%i4) declare(z,complex);
(%o4) done
(%i5) sqrt(1/z);
(%o5) 1/sqrt(z)
(%i6) log(1/z);
(%o6) -log(z)
(%i7) radexpand:false$
(%i8) sqrt(1/z);
(%o8) 1/sqrt(z)
(%i10) log(1/z);
(%o10) -log(z)
Another problem is, that the behavior of options variables like
radexpand, domain, number_pranch, ... is not well documented and not
completely implemented.
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
For this values the standard simplification is
sqrt(1/x) -> 1/sqrt(x)
log(1/x) -> -log(x)
x can be any expression including expressions which are obviously
complex, negative or contain variables which have been declared to be
complex. This is the old behavior. It might be useful to mention in the
documentation that it is not guaranteed do get equivalent results when
inserting values in simplified expressions which contain sqrt and log
functions.
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)
To get this behavior some changes have to be reverted and the option
variable domain has to be implemented more completely.
By the way: Another interesting problem and inconsistency:
(%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
Dieter Kaiser