- CLN-list - ginac.de

CLN 1.3.6 has been released
by Richard B. Kreckel 05 Dec '19

05 Dec '19

Hi! This is a minor update fixing cross-compilation (broken in the last release). Get it from <http://www.ginac.de/CLN/>. -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>

1 0

cln 1.3.5
by Henrik Grimler 05 Dec '19

05 Dec '19

Hi, When I try to cross-compile 1.3.5 for android, with clang 8.0.7 (same with clang 9.0.0), it generates an intparam.h with: #error "Integers of type int have no binary representation!!" #error "Integers of type long have no binary representation!!" #error "Integers of type long long have no binary representation!!"[...] #error "Integer types int and unsigned int have different sizes!!" #error "Integer types long and unsigned long have different sizes!!" #error "Integer types long long and unsigned long long have different sizes!!" #error "Type char * does not fit into an intptr_t!!" I do not get the same errors with 1.3.4. It seems to due to the typedef int[<negative>] -> static_assert change done in 2f7994014542920ad6ca726fbd8d023a5f49abc2. Reverting that commit makes the build succeed again. If I compile the old type of test, everything works fine, so int main() { typedef int verify[2*((int)((int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2) == 0) - 1]; ; return 0; } compiles without errors, while the same test with static_assert int main() { static_assert((int)((int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2 * (int)2) == 0, ""); ; return 0; } fails with "test_new.cpp:3:17: error: static_assert expression is not an integral constant expression" I unfortunately do not know what the proper fix would be, but reverting 2f7994014542920ad6ca726fbd8d023a5f49abc2 makes the build succeed again at least. Best regards, Henrik Grimler

3 2

CLN 1.3.5 has been released
by Richard B. Kreckel 17 Nov '19

17 Nov '19

Hi! This release fixes a bug in scale_float(), which could throw underflow_exception even if cl_inhibit_floating_point_underflow was set to true. On the portability side, support for compilation on Windows has been improved, see the INSTALL.windows file. Also, the Elbrus 2000, Risc-V64, and MIPS rel 6 platforms are now supported. Many compiler warnings have been addressed, too. Download it from the usual place: <http://www.ginac.de/CLN/>. -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>

1 0

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

Floating point underflow
by Jan Rheinländer 01 Nov '19

01 Nov '19

Hi, trying to inhibit floating point underflow exceptions, but it doesn't seem to work. What am I doing wrong? #include <cln/cln.h> int main() { cln::cl_inhibit_floating_point_underflow = true; cln::cl_N x = 10.0; cln::cl_N ep = 100.0; cln::cl_N y = cln::expt(x, ep); cln::cl_N z = cln::expt(x, -y); } Running this program still gives me an underflow exception. Thanks for any hints. Jan

2 1

CLN switched to C++11
by Richard B. Kreckel 28 Oct '19

28 Oct '19

Hi, I've just just bumped the minimum C++ language support for the compiler to C++11. I did this because C++11 is a better language and it's widely supported by now. Sticking to C++98 would require us to sometimes write convoluted patches. All in all it's a minor thing: configure makes sure that proper compiler options are chosen and the change doesn't even break the ABI. Still, I thought I should announce this here. All my best, -richy.

3 8

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