- CLN-list - ginac.de

Build CLN for 64 bi windows
by Richard Crozier 28 Oct '19

28 Oct '19

Dear list, Kaveh, I am trying to build CLN for windows 64 bit. I'm actually doing this by cross-compiling form linux using M Cross Environment (see www.mxe.cc for more information). When I try to build I get the folloinwg error: libtool: compile: x86_64-w64-mingw32.static-g++ -DHAVE_CONFIG_H -I. -I../autoconf -I../include -I../src -I../include -I../src -g -O2 -MT base/cl_as_exception.lo -MD -MP -MF base/.deps/cl_as_exception.Tpo -c base/cl_as_exception.cc -o base/cl_as_exception.o libtool: compile: x86_64-w64-mingw32.static-g++ -DHAVE_CONFIG_H -I. -I../autoconf -I../include -I../src -I../include -I../src -g -O2 -MT base/cl_condition.lo -MD -MP -MF base/.deps/cl_condition.Tpo -c base/cl_condition.cc -o base/cl_condition.o In file included from ./base/cl_sysdep.h:10:0, from base/cl_alloca.cc:4: ../include/cln/intparam.h:26:2: error: #error "Type char * does not fit into a long!!" #error "Type char * does not fit into a long!!" I noticed in a thread from eight years ago that this same problem existed back then: https://www.ginac.de/pipermail/cln-list/2011-February/000607.html Is it a huge amount of work to fix this? Did Kaveh ever share the work he did on it? Best regards, Richard

3 3

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

Re: [CLN-list] [GiNaC-list] how to convert CLN __float128 and long double?
by Richard B. Kreckel 22 Apr '19

22 Apr '19

Hello Feng Feng, On 15.04.19 01:10, Feng Feng wrote: > I wonder if there is a way to convert the cl_N or GiNaC numeric type to c++ __float128 or long double? since the both also appear in CUBA. I don't konw what long double is in CUBA, but in general it may vary between platforms. But conversion to and from fp128 types would make sense, IMO. In any case, this has little to do with GiNaC and is best discussed on cln-list(a)ginac.de (cross posting there). Best, -richy. -- <https://in.terlu.de/~kreckel/>

1 0

Re: [CLN-list] automake-1.14 dependency
by Bruno Haible 29 Mar '19

29 Mar '19

Hi Luc, > I used the cln-1.3.4.tar.bz2. > ... > make: *** [Makefile:488: /path/to/source/cln-1.3.4/Makefile.in] Error 1 This tarball works fine for me. Therefore we need more details: 1) Result of uname -sr 2) Result of make --version 3) Result of ls -lt --full-time Makefile.in Makefile.am aclocal.m4 m4/alloca.m4 \ m4/as-underscore.m4 m4/cc.m4 m4/floatparam.m4 m4/general.m4 \ m4/gettimeofday.m4 m4/gmp.m4 m4/intparam.m4 m4/lib-ld.m4 m4/lib-link.m4 \ m4/lib-prefix.m4 m4/libtool.m4 m4/lib-prefix.m4 m4/libtool.m4 \ m4/longdouble.m4 m4/longlong.m4 m4/ltoptions.m4 m4/ltsugar.m4 \ m4/ltversion.m4 m4/lt~obsolete.m4 m4/param.m4 m4/perror.m4 m4/proto.m4 \ m4/rusage.m4 m4/times.m4 configure.ac (Makefile.in should be the newest file among all these.) 4) Result of df -m . Bruno

2 2

automake-1.14 dependency
by Luc de Jonckheere 29 Mar '19

29 Mar '19

Hi CLN mailing list, When I built CLN, it failed making it. "autoconf/missing" requires automake-1.14. This dependency isn't listed in the install/build documentation ( https://www.ginac.de/CLN/cln.html#Installing-the-library) Building was successful after installing this dependency. I think it should either be listed 1.14 is specifically needed, or the source should be edited to support the latest version (which is 1.16 at the moment). With kind regards, Luc

3 3

Shift overflow?
by David van der Spoel 07 Jan '19

07 Jan '19

Hi, I am compiling 1.3.4 using gcc 8.2 and get these warnings: ./base/cl_macros.h:119:26: warning: result of '(2 << 63)' requires 66 bits to represent, but 'long long in' only has 64 bits [-Wshift-overflow=] #define bitm(n) (2LL<<((n)-1)) ~~~^~~~~~~~~ any clue? Cheers, -- David van der Spoel, Ph.D., Professor of Biology Head of Department, Cell & Molecular Biology, Uppsala University. Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205. http://www.icm.uu.se

2 1

cln: MIPS release 6 support patch
by YunQiang Su 18 Mar '18

18 Mar '18

We are working on MIPS release 6 port of Debian, and fix a problem of cln. MIPS release 6 is not full compatible with the previous releases, it removes some instructions and changes encoding of some instruction. the `multu' is included. MIPS r6 drops `lo' and `hi' registers, and then removes `multu'/`mfhi'/`mflo'. Instead it uses `mulu' to compute the low part and `muhu' to compute the high part. Index: cln-1.3.4/src/base/cl_low.h =================================================================== --- cln-1.3.4.orig/src/base/cl_low.h +++ cln-1.3.4/src/base/cl_low.h @@ -273,10 +273,15 @@ inline uint32 mulu32_unchecked (uint32 a unused (hi_zuweisung _hi); lo_zuweisung _lo; \ }) #elif defined(__GNUC__) && defined(__mips__) && !defined(NO_ASM) + #if __mips_isa_rev >= 6 + #define MULTU_HI_LO "mulu %1,%3,%2 ; muhu %0,%3,%2" + #else + #define MULTU_HI_LO "multu %3,%2 ; mfhi %0 ; mflo %1" + #endif #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ({ var register uint32 _hi; \ var register uint32 _lo; \ - __asm__("multu %3,%2 ; mfhi %0 ; mflo %1" \ + __asm__(MULTU_HI_LO \ : "=r" (_hi), "=r" (_lo) \ : "r" ((uint32)(x)), "r" ((uint32)(y)) \ ); \ Index: cln-1.3.4/src/base/digitseq/cl_asm_mips_.cc =================================================================== --- cln-1.3.4.orig/src/base/digitseq/cl_asm_mips_.cc +++ cln-1.3.4/src/base/digitseq/cl_asm_mips_.cc @@ -88,9 +88,14 @@ DECLARE_FUNCTION(mulu32_) .ent mulu32_ // Input in $4,$5, Output in $2,mulu32_high mulu32_: +#if __mips_isa_rev >= 6 + mulu $2,$5,$4 // arg1 * arg2, lo + muhu $6,$5,$4 // arg1 * arg2, hi +#else multu $5,$4 // arg1 * arg2 mfhi $6 // hi mflo $2 // lo +#endif sw $6,mulu32_high // hi abspeichern // Adressierung?? Deklaration?? j $31 // return .end mulu32_ -- YunQiang Su

2 1

Question about compiler warning
by Jan Rheinländer 13 Mar '18

13 Mar '18

Hi, in integer/gcd/cl_I_gcd_aux2.cc there are the lines (starting at line 76): void partial_gcd (uintDD z1, uintDD z2, partial_gcd_result* erg) { var uintD x1 = 1; ... line 100: if (qx > (uintDD)(~x1)) { The compiler tells me that after taking the bitwise complement of x1, the (uintDD) cast will extend x1 by adding zeros, which is probably not the intention? See https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compi… Regards, Jan Rheinländer

3 4

win64 build
by Jan Rheinländer 24 Feb '18

24 Feb '18

Hi, I'm trying to create a win64 build of CLN. Most of the changes seem to involve replacing "unsigned long" with "uintptr_t" since "long" is 32bit in Win64. To make these changes useable for the community (by way of a git patch?), should I a) just go ahead and change b) put all the changes into a #if defined(_M_AMD64) <changed code> #else <original code> #endif I refer specifically to the "unsigned long" to "uintptr_t" changes, not to all changes in general. Is there any danger in doing this change on other platforms? Best regards, Jan Rheinländer

3 3

Integer parser
by Thomas Luthe 03 May '17

03 May '17

Hi, I am writing my own parser for expressions and want to use cln for parsing integers within these expressions, specifically using read_integer (const cl_read_flags& flags, const char * string, const char * string_limit, const char * * end_of_parse) . Unfortunately this fails with a cln::read_number_bad_syntax_exception if the integer immediately precedes a "/" (example attached). I have traced the cause back to line 119 in cl_I_read.cc. My suspicion is that the check for "/" originates from the rational case (as the file states that the code is a condensed version of read_rational()) and could simply be removed, but I am not familiar enough with the code to be certain this would not break other use cases. Even though I can work around this by to determining the end of the integer before the call and setting string_limit accordingly, I would appreciate a fix for this issue. Cheers, Thomas Luthe

3 4