On 10/31/2010 6:11 PM, Dieter Kaiser wrote:
> Am Sonntag, den 31.10.2010, 14:43 -0700 schrieb Richard Fateman:
>> On 10/31/2010 2:27 PM, Edwin Woollett wrote:
>>> 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.
>> Just to make sure you understand my perspective: I view this as wrong.
>>
>> Even if z is real and positive, there are still two values of sqrt(z),
>> and the choice
>> of which one to use depends on which one you wish to use.
> I have three questions about the square root function:
>
> 1.
>
> Is it the desired behavior of Maxima to return the principal square root
> for numbers?
>
> sqrt(4) -> 2
> sqrt(-4) -> 2*%i
>
> This is the implementation we have for real and complex numbers.
This convention is inadequate, as I mentioned previously. If fixed
rational roots of fixed constants
are always reduced to a single value, then what do you do with (-1)^(1/8)?
This idea does not generalize. The fact that this behavior sqrt(4) ->2
is part of Maxima
does not mean it is right. It just means that it often works when you
are constrained to
provide a single answer, which must be either 2 or -2. Under these
circumstances, -2 is not more correct than 2.
But rootof(x^2-4,x) or the set {-2,2} might be better.
> 2.
>
> Is it the desired behavior of Maxima not to simplify
>
> sqrt(1/z) -> 1/sqrt(z) for any z?
By default, I think it should not simplify. And whether it simplifies
or not
should not depend on any assumptions on z.
It is possible to apply particular programs, e.g. radcan, to make some
simplifications, but these are NOT always correct.
> A consequence is, that
>
> sqrt(z)*sqrt(1/z) would not simplify to 1 for z>0.
Just call radcan on it.
It should not matter what z is.
radcan(sqrt(z)*sqrt(1/z)) should result in 1. THIS IS NOT A CANONICAL,
ALWAYS CORRECT SIMPLIFICATION! Radcan sometimes does something
that the user might not agree with.
radcan says, in effect, that in an expression that includes sqrt(a),
sqrt(1/a), sqrt(a*b), ..
that all the sqrt(a) expressions are the same. IT DOESN'T SAY WHICH
sqrt(a) has
been chosen.
> The current behavior of Maxima is to simplify sqrt(1/z) -> 1/sqrt(z), if
> Maxima can deduce z>0. Until Maxima 5.20 we had sqrt(1/z) -> 1/sqrt(z)
> and sqrt(z)*sqrt(1/z) -> 1 for any z.
It is wrong, in my opinion, for the choice of the branch for sqrt(z) to
depend on assumptions on z.
There are 8 roots of (-1)^(1/8). What assumptions about (-1) can you
make to choose
a branch?
One can, in some systematic way, for sqrt(polynomial) try to choose one
particular branch,
and then denote the other by -sqrt(polynomial). I did this in my
dissertation. It doesn't
work all that well. It would involve generally figuring out the
limit(polynomial, var-> inf) for
some variable var. I suppose if you said to assume(var<0) one could
use limit(polynomial, var-> -inf).
> 3.
>
> Should we implement a principal square root function, which is the
> inverse of f(x):=x^2 for x>0
That is not correct. The inverse of f(x):=x^2 is not single valued,
regardless of x>0 or not.
Let g be an inverse of f.
f(3)=9, f(-3)=9
g(9) could be 3 or -3.
If you want to restrict the range of g to non-negative numbers, that is
entirely different from
saying something about the domain of g.
What you might say is to simplify sqrt(z), if we assume(sqrt(z)>0).
Instead of simplify sqrt(z), assume(z>0).
> and is extended to the complex numbers in a
> way, which is consistent with the calculation of the principal value of
> the square root function?
You can extend this to complex numbers and it is still no better,
unfortunately.
RJF