On Wednesday, July 3, 2013 2:05:05 AM UTC-7, Eric Gourgoulhon wrote:
>
>
>
> Le mercredi 3 juillet 2013 01:07:35 UTC+2, rjf a écrit :
>>
>>
>>
>> Your statement then translates to RPBSRPN(x^2) = abs(x) .
>> But then if it ir R+-->R+, the abs() is unnecessary, and RPBSRPN(x^2) =
>> x.
>>
>>
Le mercredi 3 juillet 2013 01:07:35 UTC+2, rjf a écrit :
>
>
>
> Your statement then translates to RPBSRPN(x^2) = abs(x) .
> But then if it ir R+-->R+, the abs() is unnecessary, and RPBSRPN(x^2) =
> x.
>
>
No, the abs is necessary: consider the following function:
f : R --> R+, x |--> RPBS
On Tuesday, July 2, 2013 4:48:54 AM UTC-7, Eric Gourgoulhon wrote:
>
>
>
> Le mardi 2 juillet 2013 02:38:44 UTC+2, rjf a écrit :
>>
>>
>>
>> What you've written is just a hack.
>>
>
> Of course it's a hack; this is why I did not submit it as a patch for Sage.
> As far as one restricts oneself
Le mardi 2 juillet 2013 02:38:44 UTC+2, rjf a écrit :
>
>
>
> What you've written is just a hack.
>
Of course it's a hack; this is why I did not submit it as a patch for Sage.
As far as one restricts oneself to the REAL DOMAIN, I think it works.
Please show me a counter-example.
Again, let
On Sunday, June 30, 2013 1:23:50 PM UTC-7, Eric Gourgoulhon wrote:
...
> . It is not optimal but it works:
>
It works on this example in your opinion. If you want to deal with square
roots in this
case using some bogus relationship between the choice of branch and some
alleged
internal "si
On Sun, 30 Jun 2013 13:23:50 -0700 (PDT)
Eric Gourgoulhon wrote:
> Meanwhile, I've written the following workaround in python:
> basically, it scans all the sqrt's in a given symbolic expression,
> send them to radcan, takes the absolute value of the output and then
> calls simplify(). It is not
Le vendredi 21 juin 2013 07:00:54 UTC+2, rjf a écrit :
>
> Yes, I wrote radcan. The full source of it is available. I think it is in
> file rat3e.lisp. Look for
> (defun $radcan
> or perhaps (defmfun $radcan
>
> I think that if you wish to modify it to make a function with another
> name, you
On Thursday, June 20, 2013 1:04:51 AM UTC-7, Eric Gourgoulhon wrote:
>
> Thanks for your explanation. So it is clear that radcan ignore assumptions.
> As already mentioned by kcrisman, radcan does not take into account the
> option variable radexpand, which, if set to 'true' (and domain to 'real
Thanks for your explanation. So it is clear that radcan ignore assumptions.
As already mentioned by kcrisman, radcan does not take into account the
option variable radexpand, which, if set to 'true' (and domain to 'real'),
would do the job, as suggested in the documentation
http://maxima.sourcef
On 06/19/2013 03:03 AM, Eric Gourgoulhon wrote:
>
> Thanks for your explanation regarding how radcan works.
>
> If radcan ignores assumptions, how can one explain the following behavior:
>
> sage: assume(x<0)
> sage: sqrt(x^2).simplify_radical()
> x
> sage: maxima_calculus.eval('domain:real')
>
Thanks for your explanation regarding how radcan works.
If radcan ignores assumptions, how can one explain the following behavior:
sage: assume(x<0)
sage: sqrt(x^2).simplify_radical()
x
sage: maxima_calculus.eval('domain:real')
'real'
sage: sqrt(x^2).simplify_radical()
-x
It seems that assuming
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(
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
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
>
>
> 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).
>
>
Yes, I think that is broken. Or at any rate the documentati
15 matches
Mail list logo
