[CLN-list] [GiNaC-devel] evalf() on cube roots

[Richard B. Kreckel]

Hi,

This is a CLN topic. Let's take this thread to cln-list.

Your proposal seems to suggest that CLN pick another branch cut for
roots if a certain global flag is set.

I'm sceptical about introducing global flags which control the
computation in a way that results in very different numerical results -
it looks like calling for problems. Admitted, there are global flags
(cl_inhibit_floating_point_underflow and those dealing with I/O), and
rounding control is well known from IEEE754. But returning a complex
number which is far away from the conventional result in the complex
plane is a different thing. I'm not aware of any such flag in another
system; is there one?

I'ld like to hear what others think.

  -richy.
-- 
Richard B. Kreckel
<https://in.terlu.de/~kreckel/>

On 31.10.18 18:02, Jan Rheinländer wrote:
> Picking up this old thread...
> 
> I would like to submit a patch that allows choosing the convention for
> negative cube roots between the solution on the principal branch and the
> real-valued solution.
> 
> That is, in the cln library, file complex/transcendental/cl_C_expt_C.cc
> I would like to handle the following case separately:
> 
> y rational and y ratio m/n
> x rational and x < 0
> n odd
> 
> What about introducing a flag called (e.g.)
> cln::cl_odd_roots_of_rationals_real (similar to
> cln::cl_inhibit_floating_point_underflow)?
> 
> If the flag is false (default), the above case evaluates to exp(log(x) *
> y) as before
> 
> If the flag is true, it evaluates to (-1)^m * (-x)^(m/n)
> 
> Would such a patch be acceptable?
> 
> Greetings,
> 
> Jan Rheinländer
> 
> 
> Am 02.08.2015 um 21:55 schrieb Richard B. Kreckel:
>> On 08/02/2015 08:59 PM, Jan Rheinländer wrote:
>>>> There isn't. GiNaC, like almost all other systems, returns the solution
>>>> on the principal branch, compatible with exp(log(-1)/3).
>>> I suppose there is some excellent mathematical reason for this...
>> Actually, there isn't. Branch cuts are a matter of convention.
>> Nothing more but also nothing less.
>>
>>> but for
>>> me it means that I can't use GiNaC to verify Cardano's formula for a
>>> cubic function:
>>>
>>>> x = (-1 - sqrt(2))^(1/3) + (-1 + sqrt(2))^(1/3);
>>> (-1-sqrt(2))^(1/3)+(-1+sqrt(2))^(1/3)
>>>
>>>> evalf(x^3 + 3 * x + 2);
>>> 3.3544445609126528848+8.9073474964875349776*I
>>>
>>> Surely there must be a way to verify such a formula in GiNaC???
>> It should be straightforward to replace such rational expressions by the
>> form you want them to be in before calling evalf(), using techniques
>> such as these: <http://www.ginac.de/FAQ.html#advanced>
>>
>> Cheers
>>   -richy.
> 
> _______________________________________________
> GiNaC-devel mailing list
> GiNaC-devel at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-devel