If you don't like the semantics for square root, or for radcan  you can 
certainly
define another function and try to make its simplification and evaluation
conform to your needs.   Your "simple example" explanation is not
sufficiently simple for me, but if you do this in Maxima:

 E :  r/ (1+sqrt(1+r^2)) , r=2*R/(1-R^2);

F: radcan(E)

you get a value for F of  -1/R,  which is true, as R-> infinity.
Since      RADCAN IGNORES ASSUMPTIONS and treats all variables
in the radicals as they increase beyond bounds to choose a sign,   this is 
the right answer.

If you want to evaluate the expression E, 
(2*R)/((1-R^2)*(sqrt((4*R^2)/(1-R^2)^2+1)+1))

without such simplification at a point p between 0 and 1,
you will  find that E evaluates to p.  (actually between -1 and 1).

Also, you might find it potentially useful to use radcan as intended, and 
note that 

radcan( substitute (1/w, R, E))  is  1/w   [[ meaning that near zero, 
E(p)=p ]]


RJF




On Tuesday, June 18, 2013 2:19:19 AM UTC-7, Eric Gourgoulhon wrote:
>
> I do agree that a complex number has two square roots. Let me illustrate 
> my point of view on a simple example, on which actually I faced the problem.
> I am using Sage to do differential geometry and in particular to 
> manipulate various charts on a manifold. 
> Let us consider the hyperbolic space H^2. The polar chart (R,phi) 
> associated with the Poincaré disk model of H^2 is related to the chart 
> (r,phi') associated with the hyperboloidal model by the following 
> transformations: phi'=phi and
> r = 2*R/(1-R^2)  <==> R = r / (1 + sqrt(1+r^2)) 
> R in [0,1), r in [0, +infinity)
>
> Now in Sage:
>
> sage: R = var('R')
> sage: assume(R>=0) ; assume(R<1)
> sage: r = 2*R/(1-R^2)
> sage: R == ( r / (1+sqrt(1+r^2)) ).simplify_full()
> R == -1/R
>
> which is false and is very annoying when manipulating fields defined on 
> H^2, when passing from one chart to the other. 
>
> A solution could be to define two functions:
> - sqrt(x): the current one, which returns one of the two square roots of 
> x, with no control of which one
> - sqrt_real(x), which assumes x is real and positive and always returns 
> the positive root of x, so that sqrt_real(x^2) = abs(x) would be guaranteed.
>
> Eric.
>
> Le lundi 17 juin 2013 17:49:07 UTC+2, rjf a écrit :
>>
>> Since your belief about what the correct behavior is, is at best
>> arguable, and at worst, wrong, I would not expect it to
>> be "corrected"
>>
>> Sqrt(anything)   has TWO values.
>> Choosing one should depend on the choice of square root branch, e.g.
>> assume(sqrt(E))
>>
>> assuming something about E doesn't say much.
>>
>> e.g. even sqrt(9)  is +-3.
>> who cares about the "sign" of 9.
>>
>> In some engineering and physical circumstances, a branch of the sqrt
>> can be intuited.  But the math issue is not resolved by "assume(x>0)"  etc
>>
>>
>>
>> On Saturday, June 15, 2013 8:31:02 AM UTC-7, Eric Gourgoulhon wrote:
>>>
>>> Hi,
>>>
>>> Here is some behavior of Sage which can be quite disturbing for a new 
>>> user and probably would be considered as a bug:
>>>
>>> sage: assume(x<0)
>>> sage: sqrt(x^2).simplify_full()
>>> x
>>>
>>> It appears that the instruction "assume(x<0)" is not sufficient to 
>>> enforce the desired behavior: x is still considered as a complex number and 
>>> sqrt(x^2) returns *a* square root of x^2, not necessarily the positive one. 
>>> To enforce x real, one should set:
>>>
>>> sage: maxima_calculus.eval('domain:real')
>>> 'real'
>>>
>>> Then the output of simplify_full() is correct:
>>>
>>> sage: sqrt(x^2).simplify_full()          
>>> -x
>>>
>>> But the following problem remains:
>>>
>>> sage: sqrt((x-1)^2).simplify_full()  # correct result:
>>> -x + 1
>>> sage: sqrt(x^2-2*x+1).simplify_full() # wrong result (and not consistent 
>>> with the above):
>>> x - 1
>>>
>>> I know that the problem is due to Maxima function randcan and has been 
>>> much discussed, in particular here:
>>> http://www.math.utexas.edu/pipermail/maxima/2011/026097.html
>>> What is the latest status of this ? In particular, is there any 
>>> possibility to enforce the correct behavior by passing some options to 
>>> Maxima ? (I've noticed that maxima_calculus.eval('radexpand:true') does not 
>>> help). 
>>> Thank you for your help. 
>>>
>>> Eric.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to