- CLN-list - ginac.de

construction of cl_F from long double
by GiulianoDammando＠libero.it 22 Mar '12

22 Mar '12

Hi, i'm getting the following error when using the cln::cl_float function with a long double argument lanczos.cpp:4119:70: error: call of overloaded ‘cl_float(long double, const cln::float_format_t&)’ is ambiguous /opt/local/include/cln/float.h:69:19: note: candidates are: const cln::cl_F cln::cl_float(const cln::cl_F&, const cln::cl_F&) /opt/local/include/cln/float.h:76:19: note: const cln::cl_F cln::cl_float(const cln::cl_F&, cln::float_format_t) /opt/local/include/cln/float.h:90:19: note: const cln::cl_F cln::cl_float(const cln::cl_I&, const cln::cl_F&) /opt/local/include/cln/float.h:97:19: note: const cln::cl_F cln::cl_float(const cln::cl_I&, cln::float_format_t) /opt/local/include/cln/float.h:110:19: note: const cln::cl_F cln::cl_float(const cln::cl_RA&, const cln::cl_F&) /opt/local/include/cln/float.h:117:19: note: const cln::cl_F cln::cl_float(const cln::cl_RA&, cln::float_format_t) /opt/local/include/cln/float.h:126:19: note: const cln::cl_F cln::cl_float(int, const cln::cl_F&) /opt/local/include/cln/float.h:128:19: note: const cln::cl_F cln::cl_float(unsigned int, const cln::cl_F&) /opt/local/include/cln/float.h:130:19: note: const cln::cl_F cln::cl_float(int, cln::float_format_t) /opt/local/include/cln/float.h:132:19: note: const cln::cl_F cln::cl_float(unsigned int, cln::float_format_t) /opt/local/include/cln/float.h:139:19: note: const cln::cl_F cln::cl_float(float, const cln::cl_F&) /opt/local/include/cln/float.h:141:19: note: const cln::cl_F cln::cl_float(double, const cln::cl_F&) /opt/local/include/cln/float.h:143:19: note: const cln::cl_F cln::cl_float(float, cln::float_format_t) /opt/local/include/cln/float.h:145:19: note: const cln::cl_F cln::cl_float(double, cln::float_format_t) /opt/local/include/cln/real.h:51:19: note: const cln::cl_F cln::cl_float(const cln::cl_R&, const cln::cl_F&) /opt/local/include/cln/real.h:58:19: note: const cln::cl_F cln::cl_float(const cln::cl_R&, cln::float_format_t) suppose this is due to a missing constructor for the long double type. I would like to know if there is any fix to this problem allowing to preserve the larger precision of the long double compared to double. Thanks in advance, Giuliano

1 0

Re: [CLN-list] I applied the patch
by Richard B. Kreckel 19 Mar '12

19 Mar '12

Hi! On 03/12/2012 05:53 PM, Alessandro PROFETI wrote: > I wasn't very fast in downloading cln source code and applying the patch. > Without the patch, the number in the last incomplete (no \n) line wasn't > read by cin >> x. > Now the behavior of operator>> is the same, the last number is read and > printed in both > cases; the next cin>>x results in an exception. > This behavior is EXACTLY what I observe when x is a double, if I compile > the file profeti.cc with the switch -DEXCEP. Great. So that is fixed now. I've committed it. > Is there a way for asking cln to behave the same way as c++ when > extracting a cl_R, > so that the code > sum = 0; > while (cin >> x) > sum = sum + x; > would compute the sum of the data, with x double or x in cl_R? > This way of coding is much simpler then > for (;;) > { > try { > cin >> x; > } catch ( ... ) { > break; > } > sum = sum + x; > } Good point. I agree that, ideally, CLN would behave the same as standard C++ when reading numbers from streams. Another issue is reading from an input stream that provides "123ABC". It seems like standard C++ reads 123 and stops there while CLN reads more and later discovers that ABC doesn't match the format. > I tried to peep in cln source code and in the code for libstdc++, but > couldn't figure out > if there is some place in cln code when one can take in account the > value of cin.exceptions() > and react to error throwing an exception when the corresponding bit is set > or returning a null reference (the default for cin >> x when x is > double) when the bit is clear. I think rather than resetting exceptions after the fact, the functions implemented in cl_*_read_stream.cc should be written to be more specific to the number format. They could then read only what is required. I'll see if I can provide a patch. Bye! -richy. PS: I'm taking this thread to the mailing list. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

cl_inhibit_floating_point_underflow
by Kåre Olaussen 30 Oct '11

30 Oct '11

Hi. I cannot get this option to work. I set is globally as follows > using namespace std; > using namespace cln; > > bool cl_inhibit_floating_point_underflow = true; But the program still aborts with the following error message: > terminate called after throwing an instance of 'cln::floating_point_underflow_exception' > what(): floating point underflow. Am I doing something wrong? Regards, Kåre Olaussen

6 9

Re: [CLN-list] compiler errors with intel c++
by Richard B. Kreckel 23 Aug '11

23 Aug '11

Hi! On 08/23/2011 12:35 PM, Tamas Istvan wrote: > It's works fine with the -fno-builtin-cos_sin option. Aha! Well you've not only found a hidden "feature", but also the secret switch to turn it off. At least, I am unable to find any reference whatsoever to that builtin or to that particular switch. I bet this is a trick to cheat in benchmarks. Surely, some common benchmark contains numeric code with a cos_sin function and they replace it with their highly tuned version. (They must be targeting at some external code: If it would be for internal use only they would've prefixed it with underscores.) But with CLN, this clever plot turns into a serious bug. On 2011.08.22. 17:30, Tamas Istvan wrote: > (Anyway, the Intel Compiler Studio is free for Linux.) Not quite: it's gratis. <http://en.wikipedia.org/wiki/Gratis_versus_libre> Best wishes, and thanks a lot for this hilarious finding! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

compiler errors with intel c++
by Tamas Istvan 21 Aug '11

21 Aug '11

Hello, When I make the cln lib with Intel C++ compiler, it gives the following error messages: /bin/sh ../libtool --tag=CXX --mode=compile icpc -DHAVE_CONFIG_H -I. -I../autoconf -I../include -I../src -I../include -I../src -O2 -xAVX -axAVX -parallel -vec-report -MT cl_C_cis.lo -MD -MP -MF .deps/cl_C_cis.Tpo -c -o cl_C_cis.lo `test -f 'complex/transcendental/cl_C_cis.cc' || echo './'`complex/transcendental/cl_C_cis.cc libtool: compile: icpc -DHAVE_CONFIG_H -I. - I../autoconf -I../include -I../src -I../include -I../src -O2 -xAVX -axAVX -parallel -vec-report -MT cl_C_cis.lo -MD -MP -MF .deps/cl_C_cis.Tpo -c complex/transcendental/cl_C_cis.cc -fPIC -DPIC -o .libs/cl_C_cis.o complex/transcendental/cl_C_cis.cc(24): error: argument is incompatible with formal parameter var cos_sin_t trig = cos_sin(x); ^ complex/transcendental/cl_C_cis.cc(31): error: argument is incompatible with formal parameter var cos_sin_t trig_a = cos_sin(a); // cos(a), sin(a) errechnen ^ compilation aborted for complex/transcendental/cl_C_cis.cc (code 2) make[1]: *** [cl_C_cis.lo] Error 1 make[1]: Leaving directory `/home/cln-1.3.2/src' make: *** [all-recursive] Error 1 Slackware Linux 64bit Kernel version 2.6.37.6 Intel i5-2400 proc. Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.0.4.191 Build 20110427 Copyright (C) 1985-2011 Intel Corporation. Added compiler options: -O2 -xAVX -axAVX -parallel -vec-report What can I do to correct this? Thanks. Tamas Istvan

2 1

CLN 1.3.2 has been released
by Richard B. Kreckel 08 May '11

08 May '11

Hi! This release fixes a bug on x86 when the scale factor of scale_float(cl_LF, cl_I) exceeded 2^31. In addition, it improves portability to non-GCC compilers. Download it from the usual place: <http://www.ginac.de/CLN/>. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

Upcoming release
by Richard B. Kreckel 01 May '11

01 May '11

Hi! Later this weekend I plan to fix the problem with scale_float on x86 reported by Michael Miller and then release CLN 1.3.2 in a couple of days. Could someone please check whether the problems on MSVC have been sorted out in current master HEAD? They should, after a recent commit, but I cannot test it. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

3 6

CLN patch 3 for MSVC
by Jan 14 Mar '11

14 Mar '11

Hi, here is a simple one correcting some unclear code (at least from the point of view of the pedantic MSVC compiler). 1. Added const because the original declaration in the header file also has it 2. Added double to resolve ambiguities in which log() function is meant With this patch and the two others I sent earlier CLN compiles with MSVC and all tests pass successfully. Jan

2 2

CLN MSVC Patch 2
by Jan 12 Mar '11

12 Mar '11

Hi, here is another exasperating patch: If I compile the following code with MSVC (taken from number.h, I only added the extra qualification cln:: to illustrate the problem) namespace cln { inline _class_::_class_ (const unsigned long wert) { extern cl_private_thing cl_I_constructor_from_UL (uint32 wert); pointer = cln::cl_I_constructor_from_UL(wert); } } then I get the following error: ./include\cln/number.h(230) : error C2039: 'cl_I_constructor_from_UL' : is not a member of 'cln' and of course without the cln:: qualification I get linker errors for unresolved symbols because in cl_I_from_UL.cc the function is clearly defined inside the cln namespace. If I change the code to namespace cln { extern cl_private_thing cl_I_constructor_from_UL (uint32 wert); inline _class_::_class_ (const unsigned long wert) { pointer = cln::cl_I_constructor_from_UL(wert); } the errors disappear. I know that it is not desirable to move the extern declaration outside of the function body. But for MSVC this appears to be the only way to force the compiler to put it into the cln namespace. Therefore I would propose the following patch for MSVC only: // At the beginning of the file #ifdef _MSC_VER namespace cln { extern cl_private_thing cl_I_constructor_from_UL (uint32 wert); } #endif and the extra cln:: qualification as shown above. This is the solution with the smallest changes. But of course it would also be possible to create two versions of the inline functions and choose the right one with _MSC_VER. Please give me your opinions before I start any big edits. Thanks, Jan

1 0

Floating point overflow discrepancy
by Michael Miller 28 Feb '11

28 Feb '11

The following code (to calculate x^100000): cl_R x="1.0L100000", y=1; for (int i=1; i<=100000; i++) y=x*y; cout << y << "\n"; cout << exp(100000*ln(x)) << "\n";; results in the output 1.00000000000000302104L10000000000 terminate called after throwing an instance of 'cln::floating_point_overflow_exception' what(): floating point overflow. Aborted I know that these are very large numbers, but the two calculations are computing the same value. If the first doesn't overflow, then why does the second? Mike

2 3