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.
You can assert some disambiguation so as to try to avoid a situation in
which
there are 2 or more instances of sqrt(<some expression> ) so you keep
the same
interpretation. You can even try (as here) to make sure that sqrt(A*B)
is consistent
with sqrt(A)*sqrt(B) when they occur in the same expression. That does NOT
mean that the sign of z determines the sign of sqrt(z).
In one chapter in my phd dissertation I discuss one way of choosing. It
does NOT
require (or use) assumptions. It assumes some ordering among variables, e.g.
x<y<z. It then picks the leading term, and finds, in the limit as all
variables go to +infinity,
the sign of the radicand. It makes that sign positive, if necessary by
factoring out
a root of (-1).
All (unnested) radicals should then be consistently "signed".
This is what radcan does. When it appears that radcan is affected by
assumptions,
that is because either the input or the output of radcan is transformed,
and does not
affect the radcan algorithm. At least the way it was written originally.
RJF