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.
Hi, any opinion on the subject below? I don't really want to code a patch that never gets accepted later... -------- Weitergeleitete Nachricht -------- Betreff: [GiNaC-devel] evalf() on cube roots Datum: Wed, 31 Oct 2018 18:02:50 +0100 Von: Jan Rheinländer <jrheinlaender@gmx.de> An: GiNaC development list <ginac-devel@ginac.de> 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.
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@ginac.de https://www.cebix.net/mailman/listinfo/ginac-devel
participants (2)
-
Jan Rheinländer
-
Richard B. Kreckel