Am Freitag, den 29.10.2010, 14:02 -0700 schrieb Edwin Woollett:
> Dieter, I'm sure you are hyperaware of everything below,
> but some mailing list readers might benefit from knowing that
> the bug report you have referred to
>
> BUG ID: 1010768 - sqrt(1/z) - 1/sqrt(z) => 0
>
> has a link to the text file:
>
> http://www.math.unm.edu/~wester/demos/ComplexDomain/Macsyma.problems
>
> by Michael Wester of the Mathematics Department at the University of
> New
> Mexico,
> Albuquerque, reviewing the use of Macsyma with complex expressions,
> and
> this
> review might be useful for some readers.
>
> This file is dated 1999 and uses Macsyma 422.0 for Sparc (Solaris
> 2.x)
> computers.
>
> Lines 128 - 175 appear to show careful and correct treatment of
>
> expr : sqrt(1/z) - 1/sqrt(z);
>
> which is not simplified unless various further information about z is
> furnished. declare (z, complex) does not cause simplification, but
> remove(z, complex)$ and assume(z > 0)$ causes
> ratsimp(expr) --> 0.
>
> forget(z > 0)$ and assume(z < 0)$ causes sqrt(1/z) + 1/sqrt(z);
> to be automatically simplified to 0.
>
> Using the principal branch definitions for both w1 = (z)^(1/2)
> and w2 = (1/z)^(1/2) , sqrt(1/z) = 1 / sqrt(z) unless
> z is real and negative (theta = pi radians), in which case
> sqrt(1/z) = - 1 / sqrt(z).
>
> I would welcome an improvement in simplification
> of square roots of complex expressions, avoiding tedious
> hand work.
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.
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.
Dieter Kaiser