CLN-list

Download

cln-list@ginac.de

September 2019

3 participants
2 discussions

MinGW64 build
by Robert Szalai 05 Nov '19

05 Nov '19

Hi all, I've been trying to build CLN from windows 64, with some success. It compiles fine, but does not work. The problem is that WIN64 is LLP64, and not ILP64 as Linux. CLN uses long to store pointer data, but size_t or ssize_t should be used as it is guaranteed to be the size of the pointer everywhere. The attached patch was my attempt. Could somebody tell me where else should I look? Pointers are also encoding some metadata in the bits that are set to zero by alingnment, what is this data? There is also some hashing of pointers. Thanks, Robert

6 21

Re: [CLN-list] [GiNaC-devel] evalf() on cube roots
by Richard B. Kreckel 22 Sep '19

22 Sep '19

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(a)ginac.de > https://www.cebix.net/mailman/listinfo/ginac-devel

3 3