On Oct. 30 Dieter Kaiser wrote:
-----------------------------------
> Yes, you are right, to correct the bug sqrt(1/z) -> 1/sqrt(z) for z<0,
> at first this type of simplification has been switched of completely. In
> a next step this type of simplification has been made available for z>0.
----------------------------------------------------
The original bug you mentioned in your note of 8-30-09
was that sqrt(1/z) automatically simplified to 1/sqrt(z)
irrespective of declarations.
I agree that the first step is to remove that bug and allow the
simplification to occur if z is real and positive. The
desired simplification for z real and negative, which
apparently is produced by Macsyma was what I was
wondering about.
We need sqrt(1/z) --> - 1/sqrt(z) for z < 0 so that the expression
I defined in my note will correctly simplify to zero.
The Maxima user can always simplify by hand, as in:
(%i1) [display2d:false,fpprintprec:6]$
(%i2) expr : sqrt(1/z) + 1/sqrt(z);
(%o2) 1/sqrt(z)+sqrt(1/z)
(%i3) assume(a>0)$
(%i4) subst (z = -a, expr);
(%o4) 0
--------------------------------
> In general it is not difficult to do a more complete check including
> complex numbers, e. g. the function conjugate does this. The problem is,
> that this type of simplification happens in the core simplifier. Adding
> more and more special cases which need a lot of processing time in the
> core simplifier might significantly slow down the simplifier.
> Therefore it is important to decide what really should be the desired
> default simplification of expressions like sqrt(1/z) for complex numbers
> and a lot of other simplification problems, too.
> Since some time I am working through the functions of the core
> simplifier to find the wrong and arguable results and to find possible
> improvements. One example is the multiplication of zeros, another
> example is the simplification of powers of complex and negative numbers.
> Furthermore, I try to document the default behavior and to write test
> files which check this default behavior. The test files should make sure
> that we do not change a desired default behavior in the future.
> A next problem is the behavior of the global flags like radexpand,
> domain, ... These flags should be implemented much more consistent, e.g.
> we might define that radexpand:all means "The arguments to the power
> function are assumed to be real and positive". With the help of a more
> clear definition we can implement the behavior of global switches much
> more consistently.
> I will think about this problem and I try to suggest a solution.
----------------------------------------------------------
Thank you for your explanation of the current status of this issue,
and thank you for your dedicated work on these problems.
I agree that the highest priority is to "do no harm", ie.,
don't return wrong answers.
I also agree that speed of simplification may be degraded
if the arguments of multivalued functions are fully
interrogated for reasonable simplifications.
The idea of (yet another) global switch, complex_simp_flag
say, would allow users to decide where their priorities lie
on a particular problem.
Another issue is the absence (I think) in the help
manual of information on Maxima's choice of branch cuts
for multivalued functions.
The Mathematica manual has several pages of information
on this subject.
Of course the Maxima user can experiment with
closedly spaced points on opposite sides of a
guessed at branch cut to see how much difference
occurs in the function value, as in:
---------------------------------------------
(%i5) zlist : [ -2 + 0.1*%i, -2 - 0.1*%i]$
(%i6) log (zlist);
(%o6) [3.09163*%i+0.6944,0.6944-3.09163*%i]
(%i7) exp (%);
(%o7) [0.1*%i-2.0,-0.1*%i-2.0]
(%i8) sqrt (zlist);
(%o8) [1.41466*%i+0.03534,0.03534-1.41466*%i]
(%i9) expand (%^2);
(%o9) [0.1*%i-2.0,-0.1*%i-2.0]
-----------------------------------------
But it would also be nice to just be able
to look this up.
Ted