We have some known problems with the log function, because Maxima does
some expansions for the log function by default, which are not correct
in general.
The following examples shows the types of errors:
(%i1) declare(z,complex)$
1. Only correct for special values of z and x, e.g. z>0 and x a real
value (See Bug report ID: 3007061):
(%i2) log(z^x);
(%o2) x*log(z)
2. Wrong for z a negative real value:
(%i3) log(1/z);
(%o3) -log(z)
3. Wrong for z a complex value with abs(imagpart(z)) > %pi:
(%i4) log(exp(z));
(%o4) z
I think the default behavior of Maxima should be to do only
simplifications which are correct in general. Therefore, I have tried
the following:
1. Set the default value of $logexpand to NIL in simp.lisp
This way we do not get wrong simplifications for the examples
1. and 2. from above.
2. Check for complex expression when simplifying log(exp(z))
This is to get correct simplifications for the 3. example.
3. Put in some simplifications, which are correct in general:
a) log(z^(1/n)) -> log(z)/n, where n is an integer
b) log(x^a) -> a*log(x), where x>0 and a is real
c) log(exp(x)) -> x, where x is real
d) log(exp(%i*x)) -> %i*x, where x is real
4. In gruntz bind $logexpand to T
The algorithm of gruntz hangs, when $logexpand has the value NIL.
This might be called a bug of gruntz too.
With this changes it is the default behavior of Maxima to do only
simplifications for the log function which are correct in general.
We have some examples in the testsuite and one example in the
share_testsuite which depends on the the value T for $logexpand. When we
set the flag for this examples we get no further problems with the
test_suite and share_testsuite.
It is clear that we might have more user code which depends on the value
T for the option variable $logexpand. But I think, it is no problem and
much better to set the option variable $logexpand explicitly when
needed.
So the question is should we apply the suggested changes to get a log
function which simplifies more correct by default.
Dieter Kaiser