Hi, I am releasing CLN-1.2.0. This took much longer than I hoped it would, mainly because the focus of this release has been to support huge numbers, i.e. those with billions of decimal digits. And turnaround times when testing, debugging and benchmarking programs operating on numbers several GiB in size can be rather stultifying. Another major change is the introduction of C++ exceptions for error handling. The cl_abort() hook is not supported any more. This allows for much more flexible error handling on the side of your application. Please refer to the documentation to learn about existing exception types. Also, some types have changed which might require that you have a look at your application code: [su]intC is used for counter loops, [su]intE for exponents of all floating-point numbers, and cl_boolean has been replaced with standard C++ bool. As is to be expected, if one pushes the limits of known digits, memory consumption becomes a critical issue. So, CLN 1.2.0's constants and transcendental functions are noticeably more memory efficient than in previous releases. There are two reasons for this: First, more use has been made of the streamed binary splitting implementation, only used casually in earlier versions: There, the rational series terms are not precomputed before starting the binary splitting algorithm but rather computed when they are needed. The second reason is that while performing the binary splitting, some intermediate integer results may become much larger than the result's precision warrants. As it turns out, that excess precision can simply be truncated by coercing the result into a cl_LF of appropriate length. Basically, this compresses the extra digits into the floating-point exponent. With some rational series, the savings are dramatic. As an extreme example, attached is a picture of the memory footprint when computing one million decimal digits of Euler's gamma. The red curve corresponds to CLN-1.1.x while the blue one to CLN 1.2.0. Here, making the operands smaller even saves computing time. The library has undergone tests with operands of billions of decimal digits and I have stopped finding errors many months ago. This makes me confident to trust a computation of over 1 billion decimal digits of Euler's constant gamma which took one week (and another week for a verification on another machine with even higher precision). Instead of pasting the result here, let me just write it in regexpese: decimal(gamma) =~ "0.57721566[0-9]{1001262760}39288477" According to Wikipedia [1] and Xavier Gourdon's list [2], this establishes the current world record. It more than eightfolds the previous world record by Alexander J. Yee and by the way confirms that earlier record's correctness. (I've emailed Mr. Gourdon, but he doesn't seem to be tracking numerical world records any more, so one cannot be so sure.) Oh, and last but not least, I should say a big THANK YOU to the people who made contributions to this release. You'll find the names in the ChangeLog. Enjoy -richy. [1] <http://en.wikipedia.org/wiki/Mathematical_constant> [2] <http://numbers.computation.free.fr/Constants/Gamma/gamma.html> [3] <http://numberworld.org/euler116m.html> -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
I am pleased to report that CLN-1.2.0 builds and passes all tests on OS X Leopard on a Core2 Duo. :-) rg On Jan 19, 2008, at 2:34 PM, Richard B. Kreckel wrote:
Hi,
I am releasing CLN-1.2.0. This took much longer than I hoped it would, mainly because the focus of this release has been to support huge numbers, i.e. those with billions of decimal digits. And turnaround times when testing, debugging and benchmarking programs operating on numbers several GiB in size can be rather stultifying.
Another major change is the introduction of C++ exceptions for error handling. The cl_abort() hook is not supported any more. This allows for much more flexible error handling on the side of your application. Please refer to the documentation to learn about existing exception types.
Also, some types have changed which might require that you have a look at your application code: [su]intC is used for counter loops, [su]intE for exponents of all floating-point numbers, and cl_boolean has been replaced with standard C++ bool.
As is to be expected, if one pushes the limits of known digits, memory consumption becomes a critical issue. So, CLN 1.2.0's constants and transcendental functions are noticeably more memory efficient than in previous releases. There are two reasons for this: First, more use has been made of the streamed binary splitting implementation, only used casually in earlier versions: There, the rational series terms are not precomputed before starting the binary splitting algorithm but rather computed when they are needed. The second reason is that while performing the binary splitting, some intermediate integer results may become much larger than the result's precision warrants. As it turns out, that excess precision can simply be truncated by coercing the result into a cl_LF of appropriate length. Basically, this compresses the extra digits into the floating-point exponent. With some rational series, the savings are dramatic. As an extreme example, attached is a picture of the memory footprint when computing one million decimal digits of Euler's gamma. The red curve corresponds to CLN-1.1.x while the blue one to CLN 1.2.0. Here, making the operands smaller even saves computing time.
The library has undergone tests with operands of billions of decimal digits and I have stopped finding errors many months ago. This makes me confident to trust a computation of over 1 billion decimal digits of Euler's constant gamma which took one week (and another week for a verification on another machine with even higher precision). Instead of pasting the result here, let me just write it in regexpese:
decimal(gamma) =~ "0.57721566[0-9]{1001262760}39288477"
According to Wikipedia [1] and Xavier Gourdon's list [2], this establishes the current world record. It more than eightfolds the previous world record by Alexander J. Yee and by the way confirms that earlier record's correctness. (I've emailed Mr. Gourdon, but he doesn't seem to be tracking numerical world records any more, so one cannot be so sure.)
Oh, and last but not least, I should say a big THANK YOU to the people who made contributions to this release. You'll find the names in the ChangeLog.
Enjoy -richy.
[1] <http://en.wikipedia.org/wiki/Mathematical_constant> [2] <http://numbers.computation.free.fr/Constants/Gamma/gamma.html> [3] <http://numberworld.org/euler116m.html> -- Richard B. Kreckel <http://www.ginac.de/~kreckel/> <euler.png>_______________________________________________ CLN-list mailing list CLN-list@ginac.de https://www.cebix.net/mailman/listinfo/cln-list
Ron Garret wrote:
I am pleased to report that CLN-1.2.0 builds and passes all tests on OS X Leopard on a Core2 Duo.
Good. What compiler/version is that? -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Jan 20, 2008, at 12:42 PM, Richard B. Kreckel wrote:
Ron Garret wrote:
I am pleased to report that CLN-1.2.0 builds and passes all tests on OS X Leopard on a Core2 Duo.
Good. What compiler/version is that?
[ron@mickey:~]$ gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- checking -enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ $/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic -- host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5465) [ron@mickey:~]$
* Richard B. Kreckel <kreckel@ginac.de> [Jan 20. 2008 11:13]:
Hi,
[...]
Congratulations! builds and checks fine with openSUSE 10.3 (X86-64) ... and it got faster: cln 1.1.9: % time pi 1048576 > /dev/null pi 1048576 > /dev/null 7.62s user 0.07s system 99% cpu 7.699 total cln 1.2.0: % time pi 1048576 > /dev/null pi 1048576 > /dev/null 5.76s user 0.10s system 99% cpu 5.892 total May I suggest to add a AGM based pi-computation? Two observations: by default you use (1) only -O, I suggest to use -O2 (but not -O3). (2) no warnings!, I suggest to use -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused \ -Wshadow -Wundef ... and -Werror if you are daring ... valgrind for further headaches ;-) keep up the good work! regards, jj
Hello! On Sun, Jan 20, 2008 at 12:17:51PM +1100, Joerg Arndt wrote:
by default you use (1) only -O, I suggest to use -O2 (but not -O3).
I'm not sure if CLN code is safe to compile with plain -O2. With CXXFLAGS="-m64 -O2 -Wall -march=k8 -finline-limit=2000" I get tons of warnings like ../../include/cln/number.h: In constructor 'cln::cl_number::cl_number(float)': ../../include/cln/number.h:238: warning: type-punning to incomplete type might break strict-aliasing rules ../../include/cln/number.h: In member function 'cln::cl_number& cln::cl_number::operator=(float)': ../../include/cln/number.h:238: warning: type-punning to incomplete type might break strict-aliasing rules ../../include/cln/number.h: In constructor 'cln::cl_number::cl_number(double)': ../../include/cln/number.h:239: warning: type-punning to incomplete type might break strict-aliasing rules Just for the record, I use g++-4.1 (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21).
(2) no warnings!, I suggest to use -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused \ -Wshadow -Wundef
-Wall spews a lot of warnings, and signal/noise ratio is quite low for this to be useful.
... and -Werror if you are daring
Unfortunately, CLN won't compile with -Werror. Best regards, Alexei -- All science is either physics or stamp collecting.
Hi, * Alexei Sheplyakov <varg@theor.jinr.ru> [Jan 21. 2008 12:33]:
Hello!
On Sun, Jan 20, 2008 at 12:17:51PM +1100, Joerg Arndt wrote:
by default you use (1) only -O, I suggest to use -O2 (but not -O3).
I'm not sure if CLN code is safe to compile with plain -O2.
This would be a serios problem IMHO!
With CXXFLAGS="-m64 -O2 -Wall -march=k8 -finline-limit=2000" I get tons of warnings like
../../include/cln/number.h: In constructor 'cln::cl_number::cl_number(float)': ../../include/cln/number.h:238: warning: type-punning to incomplete type might break strict-aliasing rules ../../include/cln/number.h: In member function 'cln::cl_number& cln::cl_number::operator=(float)': ../../include/cln/number.h:238: warning: type-punning to incomplete type might break strict-aliasing rules ../../include/cln/number.h: In constructor 'cln::cl_number::cl_number(double)': ../../include/cln/number.h:239: warning: type-punning to incomplete type might break strict-aliasing rules
Then -no-strict-aliasing should be used! It seems to me that with strict aliasing and ignoring the warnings we just proceed "fingers crossed" (?)
Just for the record, I use g++-4.1 (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21).
(2) no warnings!, I suggest to use -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused \ -Wshadow -Wundef
-Wall spews a lot of warnings, and signal/noise ratio is quite low for this to be useful.
I do that for my stuff all the time: I consider an warning as a problem and fix it. When I _know_ there is no problem then I use a (C-style) cast and comment it. I found quite a few subtle problems by doing this.
... and -Werror if you are daring
Unfortunately, CLN won't compile with -Werror.
Clearly so. I use -Werror and do a make -k ("keep going"), then I go through the file where the problems occur.
Best regards, Alexei
after all the above is done (a monumental task with CLN, obviously) valgrind pointed me to a few _very_ subtle problems which I'd never found by other other means! cheers, jj
Alexei Sheplyakov wrote:
I'm not sure if CLN code is safe to compile with plain -O2.
With CXXFLAGS="-m64 -O2 -Wall -march=k8 -finline-limit=2000" I get tons of warnings like
../../include/cln/number.h: In constructor 'cln::cl_number::cl_number(float)': ../../include/cln/number.h:238: warning: type-punning to incomplete type might break strict-aliasing rules ../../include/cln/number.h: In member function 'cln::cl_number& cln::cl_number::operator=(float)': ../../include/cln/number.h:238: warning: type-punning to incomplete type might break strict-aliasing rules ../../include/cln/number.h: In constructor 'cln::cl_number::cl_number(double)': ../../include/cln/number.h:239: warning: type-punning to incomplete type might break strict-aliasing rules
Just for the record, I use g++-4.1 (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21).
Attached is a proposed patch that removes most of the warnings. They cause two additional instructions to be added to the functions cl_float_to_FF_pointer and cl_double_to_DF_pointer, but this is worth the gain of being able to compile cln with -O2 with modern gcc. Richy, ok to apply? Jörg Arndt wrote:
(2) no warnings!, I suggest to use -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused \ -Wshadow -Wundef
While I agree that -Wall is generally useful, and -W is sometimes useful, the others spew too many warnings on perfectly valid code, IMO. Your mileage might vary, of course. Bruno diff -c -3 -r1.202 ChangeLog *** cln/ChangeLog 19 Jan 2008 20:50:30 -0000 1.202 --- cln/ChangeLog 21 Jan 2008 09:39:05 -0000 *************** *** 1,3 **** --- 1,30 ---- + 2007-01-20 Bruno Haible <bruno@clisp.org> + + Avoid some gcc warnings. + * autoconf/floatparam.c (flipped_double): Use a union instead of a + type-punning cast. + * include/cln/number.h (union ffloatjanus, union dfloatjanus): Remove + declarations. + (cl_float_to_FF_pointer, cl_double_to_DF_pointer): Change argument + type. + (CL_DEFINE_FLOAT_CONSTRUCTOR, CL_DEFINE_DOUBLE_CONSTRUCTOR): Update. + * src/float/dfloat/cl_FF.h (cl_float_to_FF_pointer): Change argument + type. + (cl_float_to_FF): Remove function. + * src/float/ffloat/conv/cl_FF_from_float.cc (FAST_FLOAT): Define. + (cl_float_to_FF_pointer): Change argument type. + * src/float/dfloat/cl_DF.h (cl_double_to_DF_pointer): Change argument + type. + (cl_double_to_DF): Remove function. + * src/float/dfloat/conv/cl_DF_from_double.cc (FAST_DOUBLE): Define. + (cl_double_to_DF_pointer): Change argument type. + * src/float/lfloat/cl_LF_impl.h (LF_decode): Mark the mantlen_zuweisung + assignment as possibly unused. + * src/base/cl_low.h (mulu32): Mark the hi_zuweisung assignment as + possibly unused. + * src/float/transcendental/cl_LF_zeta_int.cc (compute_zeta_cvz2): + Remove unused local variable. + 2007-01-19 Richard B. Kreckel <kreckel@ginac.de> * Version 1.2.0 released. diff -c -3 -r1.3 floatparam.c *** cln/autoconf/floatparam.c 19 Dec 2006 14:50:43 -0000 1.3 --- cln/autoconf/floatparam.c 21 Jan 2008 09:39:05 -0000 *************** *** 92,99 **** static void flipped_double (void) { typedef struct { unsigned lo, hi; } dfloat; ! double x = 2; ! dfloat test = *(dfloat*)&x; if (test.lo==0 && test.hi!=0) { printf("#define double_wordorder_bigendian_p 0\n"); } else if (test.lo!=0 && test.hi==0) { --- 92,100 ---- static void flipped_double (void) { typedef struct { unsigned lo, hi; } dfloat; ! union { dfloat eksplicit; double machine_double; } x; ! x.machine_double = 2; ! dfloat test = x.eksplicit; if (test.lo==0 && test.hi!=0) { printf("#define double_wordorder_bigendian_p 0\n"); } else if (test.lo!=0 && test.hi==0) { diff -c -3 -r1.6 number.h *** cln/include/cln/number.h 11 Dec 2006 17:31:06 -0000 1.6 --- cln/include/cln/number.h 21 Jan 2008 09:39:06 -0000 *************** *** 146,179 **** // Constructors and assignment operators from C numeric types. // from `float': ! union ffloatjanus; ! extern cl_private_thing cl_float_to_FF_pointer (const union ffloatjanus& val); #define CL_DEFINE_FLOAT_CONSTRUCTOR(_class_) \ inline _class_ :: _class_ (const float x) \ { \ ! pointer = cl_float_to_FF_pointer(*(const union ffloatjanus *)&x); \ } \ inline _class_& _class_::operator= (const float x) \ { \ cl_dec_refcount(*this); \ ! pointer = cl_float_to_FF_pointer(*(const union ffloatjanus *)&x); \ return *this; \ } // from `double': ! union dfloatjanus; ! extern struct cl_heap_dfloat * cl_double_to_DF_pointer (const union dfloatjanus& val); #define CL_DEFINE_DOUBLE_CONSTRUCTOR(_class_) \ inline _class_::_class_ (const double x) \ { \ ! pointer = cl_double_to_DF_pointer(*(const union dfloatjanus *)&x); \ } \ inline _class_& _class_::operator= (const double x) \ { \ cl_dec_refcount(*this); \ ! pointer = cl_double_to_DF_pointer(*(const union dfloatjanus *)&x); \ return *this; \ } --- 146,177 ---- // Constructors and assignment operators from C numeric types. // from `float': ! extern cl_private_thing cl_float_to_FF_pointer (const float val); #define CL_DEFINE_FLOAT_CONSTRUCTOR(_class_) \ inline _class_ :: _class_ (const float x) \ { \ ! pointer = cl_float_to_FF_pointer(x); \ } \ inline _class_& _class_::operator= (const float x) \ { \ cl_dec_refcount(*this); \ ! pointer = cl_float_to_FF_pointer(x); \ return *this; \ } // from `double': ! extern struct cl_heap_dfloat * cl_double_to_DF_pointer (const double val); #define CL_DEFINE_DOUBLE_CONSTRUCTOR(_class_) \ inline _class_::_class_ (const double x) \ { \ ! pointer = cl_double_to_DF_pointer(x); \ } \ inline _class_& _class_::operator= (const double x) \ { \ cl_dec_refcount(*this); \ ! pointer = cl_double_to_DF_pointer(x); \ return *this; \ } diff -c -3 -r1.14 cl_low.h *** cln/src/base/cl_low.h 9 Oct 2007 22:26:28 -0000 1.14 --- cln/src/base/cl_low.h 21 Jan 2008 09:39:06 -0000 *************** *** 165,171 **** var union { double f; uint32 i[2]; uint16 s[4]; } __fi; \ __fi.f = (double)(sint32)(_x)*(double)(sint32)(_y) \ + (double)(4503599627370496.0L); /* + 2^52, zum Normalisieren */\ ! hi_zuweisung __fi.s[1]; /* mittlere 16 Bit herausholen, (benutzt CL_CPU_BIG_ENDIAN_P !) */\ lo_zuweisung __fi.i[1]; /* untere 32 Bit herausholen (benutzt CL_CPU_BIG_ENDIAN_P !) */\ } #else --- 165,171 ---- var union { double f; uint32 i[2]; uint16 s[4]; } __fi; \ __fi.f = (double)(sint32)(_x)*(double)(sint32)(_y) \ + (double)(4503599627370496.0L); /* + 2^52, zum Normalisieren */\ ! unused (hi_zuweisung __fi.s[1]); /* mittlere 16 Bit herausholen, (benutzt CL_CPU_BIG_ENDIAN_P !) */\ lo_zuweisung __fi.i[1]; /* untere 32 Bit herausholen (benutzt CL_CPU_BIG_ENDIAN_P !) */\ } #else *************** *** 205,217 **** extern "C" uint32 mulu32_high; // -> High-Teil #if defined(__GNUC__) && defined(__m68k__) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ! ({ var uint32 _x = (x); \ ! var uint32 _y = (y); \ ! var uint32 _hi; \ ! var uint32 _lo; \ __asm__("mulul %3,%0:%1" : "=d" (_hi), "=d"(_lo) : "1" (_x), "dm" (_y) ); \ ! hi_zuweisung _hi; \ ! lo_zuweisung _lo; \ }) #elif defined(__GNUC__) && defined(__m68k__) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ --- 205,217 ---- extern "C" uint32 mulu32_high; // -> High-Teil #if defined(__GNUC__) && defined(__m68k__) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ! ({ var uint32 _x = (x); \ ! var uint32 _y = (y); \ ! var uint32 _hi; \ ! var uint32 _lo; \ __asm__("mulul %3,%0:%1" : "=d" (_hi), "=d"(_lo) : "1" (_x), "dm" (_y) ); \ ! unused (hi_zuweisung _hi); \ ! lo_zuweisung _lo; \ }) #elif defined(__GNUC__) && defined(__m68k__) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ *************** *** 231,237 **** _hi += high16(_mid); _mid = highlow32_0(low16(_mid)); \ _lo += _mid; if (_lo < _mid) { _hi += 1; } /* 64-Bit-Addition */\ } \ ! hi_zuweisung _hi; \ lo_zuweisung _lo; \ }) #elif defined(__GNUC__) && defined(__sparc64__) && !defined(NO_ASM) --- 231,237 ---- _hi += high16(_mid); _mid = highlow32_0(low16(_mid)); \ _lo += _mid; if (_lo < _mid) { _hi += 1; } /* 64-Bit-Addition */\ } \ ! unused (hi_zuweisung _hi); \ lo_zuweisung _lo; \ }) #elif defined(__GNUC__) && defined(__sparc64__) && !defined(NO_ASM) *************** *** 241,260 **** : "=r" (_prod) \ : "r" ((uint32)(x)), "r" ((uint32)(y)) \ ); \ ! hi_zuweisung (uint32)(_prod>>32); \ lo_zuweisung (uint32)(_prod); \ }) #elif defined(__GNUC__) && defined(__sparc__) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ({ lo_zuweisung mulu32_(x,y); /* extern in Assembler */ \ {var register uint32 _hi __asm__("%g1"); \ ! hi_zuweisung _hi; \ }}) #elif defined(__GNUC__) && defined(__arm__) && 0 // see comment cl_asm_arm.cc #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ({ lo_zuweisung mulu32_(x,y); /* extern in Assembler */ \ {var register uint32 _hi __asm__("%r1"/*"%a2"*/); \ ! hi_zuweisung _hi; \ }}) #elif defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ --- 241,260 ---- : "=r" (_prod) \ : "r" ((uint32)(x)), "r" ((uint32)(y)) \ ); \ ! unused (hi_zuweisung (uint32)(_prod>>32)); \ lo_zuweisung (uint32)(_prod); \ }) #elif defined(__GNUC__) && defined(__sparc__) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ({ lo_zuweisung mulu32_(x,y); /* extern in Assembler */ \ {var register uint32 _hi __asm__("%g1"); \ ! unused (hi_zuweisung _hi); \ }}) #elif defined(__GNUC__) && defined(__arm__) && 0 // see comment cl_asm_arm.cc #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ({ lo_zuweisung mulu32_(x,y); /* extern in Assembler */ \ {var register uint32 _hi __asm__("%r1"/*"%a2"*/); \ ! unused (hi_zuweisung _hi); \ }}) #elif defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ *************** *** 264,270 **** : "=d" /* %edx */ (_hi), "=a" /* %eax */ (_lo) \ : "g" ((uint32)(x)), "1" /* %eax */ ((uint32)(y)) \ ); \ ! hi_zuweisung _hi; lo_zuweisung _lo; \ }) #elif defined(__GNUC__) && defined(__mips__) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ --- 264,270 ---- : "=d" /* %edx */ (_hi), "=a" /* %eax */ (_lo) \ : "g" ((uint32)(x)), "1" /* %eax */ ((uint32)(y)) \ ); \ ! unused (hi_zuweisung _hi); lo_zuweisung _lo; \ }) #elif defined(__GNUC__) && defined(__mips__) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ *************** *** 274,300 **** : "=r" (_hi), "=r" (_lo) \ : "r" ((uint32)(x)), "r" ((uint32)(y)) \ ); \ ! hi_zuweisung _hi; lo_zuweisung _lo; \ }) #elif defined(__GNUC__) && defined(HAVE_LONGLONG) && !defined(__arm__) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ({ var register uint64 _prod = (uint64)(uint32)(x) * (uint64)(uint32)(y); \ ! hi_zuweisung (uint32)(_prod>>32); \ lo_zuweisung (uint32)(_prod); \ }) #elif defined(WATCOM) && defined(__i386__) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ! { var register uint32 _hi; \ ! var register uint32 _lo; \ ! _lo = mulu32_(x,y), _hi = mulu32_high_(); \ ! hi_zuweisung _hi; lo_zuweisung _lo; \ } extern "C" uint32 mulu32_high_ (void); #pragma aux mulu32_ = 0xF7 0xE2 /* mull %edx */ parm [eax] [edx] value [eax] modify [eax edx]; #pragma aux mulu32_high_ = /* */ value [edx] modify []; #else #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ! { lo_zuweisung mulu32_(x,y); hi_zuweisung mulu32_high; } #if (defined(__m68k__) || defined(__sparc__) || defined(__sparc64__) || defined(__arm__) || (defined(__i386__) && !defined(WATCOM) && !defined(MICROSOFT)) || defined(__x86_64__) || defined(__mips__) || defined(__hppa__)) && !defined(NO_ASM) // mulu32_ extern in Assembler #if defined(__sparc__) || defined(__sparc64__) --- 274,300 ---- : "=r" (_hi), "=r" (_lo) \ : "r" ((uint32)(x)), "r" ((uint32)(y)) \ ); \ ! unused (hi_zuweisung _hi); lo_zuweisung _lo; \ }) #elif defined(__GNUC__) && defined(HAVE_LONGLONG) && !defined(__arm__) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ({ var register uint64 _prod = (uint64)(uint32)(x) * (uint64)(uint32)(y); \ ! unused (hi_zuweisung (uint32)(_prod>>32)); \ lo_zuweisung (uint32)(_prod); \ }) #elif defined(WATCOM) && defined(__i386__) && !defined(NO_ASM) #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ! { var register uint32 _hi; \ ! var register uint32 _lo; \ ! _lo = mulu32_(x,y), _hi = mulu32_high_(); \ ! unused (hi_zuweisung _hi); lo_zuweisung _lo; \ } extern "C" uint32 mulu32_high_ (void); #pragma aux mulu32_ = 0xF7 0xE2 /* mull %edx */ parm [eax] [edx] value [eax] modify [eax edx]; #pragma aux mulu32_high_ = /* */ value [edx] modify []; #else #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ ! { lo_zuweisung mulu32_(x,y); unused (hi_zuweisung mulu32_high); } #if (defined(__m68k__) || defined(__sparc__) || defined(__sparc64__) || defined(__arm__) || (defined(__i386__) && !defined(WATCOM) && !defined(MICROSOFT)) || defined(__x86_64__) || defined(__mips__) || defined(__hppa__)) && !defined(NO_ASM) // mulu32_ extern in Assembler #if defined(__sparc__) || defined(__sparc64__) diff -c -3 -r1.5 cl_DF.h *** cln/src/float/dfloat/cl_DF.h 15 Sep 2007 21:34:16 -0000 1.5 --- cln/src/float/dfloat/cl_DF.h 21 Jan 2008 09:39:06 -0000 *************** *** 309,318 **** // e=2047, m=0: vorzeichenbehaftete Infinity // e=2047, m/=0: NaN ! // cl_double_to_DF(val) wandelt ein IEEE-Double-Float val in ein Double-Float um. ! extern cl_heap_dfloat* cl_double_to_DF_pointer (const dfloatjanus& val); ! inline const cl_DF cl_double_to_DF (const dfloatjanus& val) ! { return cl_double_to_DF_pointer(val); } // cl_DF_to_double(obj,&val); // wandelt ein Double-Float obj in ein IEEE-Double-Float val um. --- 309,316 ---- // e=2047, m=0: vorzeichenbehaftete Infinity // e=2047, m/=0: NaN ! // cl_double_to_DF_pointer(val) wandelt ein IEEE-Double-Float val in ein Double-Float um. ! extern cl_heap_dfloat* cl_double_to_DF_pointer (const double val); // cl_DF_to_double(obj,&val); // wandelt ein Double-Float obj in ein IEEE-Double-Float val um. diff -c -3 -r1.4 cl_DF_from_double.cc *** cln/src/float/dfloat/conv/cl_DF_from_double.cc 15 Sep 2007 21:34:16 -0000 1.4 --- cln/src/float/dfloat/conv/cl_DF_from_double.cc 21 Jan 2008 09:39:06 -0000 *************** *** 1,4 **** ! // cl_double_to_FF(). // General includes. #include "cl_sysdep.h" --- 1,7 ---- ! // cl_double_to_DF_pointer(). ! ! // Ensure that union dfloatjanus has a 'double' alternative. ! #define FAST_DOUBLE // General includes. #include "cl_sysdep.h" *************** *** 11,18 **** namespace cln { ! cl_heap_dfloat* cl_double_to_DF_pointer (const dfloatjanus& val_) { var dfloat val = val_.eksplicit; #if (cl_word_size==64) var uintL exp = (val >> DF_mant_len) & (bit(DF_exp_len)-1); // e --- 14,23 ---- namespace cln { ! cl_heap_dfloat* cl_double_to_DF_pointer (const double x) { + var union dfloatjanus val_; + val_.machine_double = x; var dfloat val = val_.eksplicit; #if (cl_word_size==64) var uintL exp = (val >> DF_mant_len) & (bit(DF_exp_len)-1); // e diff -c -3 -r1.4 cl_FF.h *** cln/src/float/ffloat/cl_FF.h 15 Sep 2007 21:34:16 -0000 1.4 --- cln/src/float/ffloat/cl_FF.h 21 Jan 2008 09:39:06 -0000 *************** *** 237,246 **** // e=255, m=0: vorzeichenbehaftete Infinity // e=255, m/=0: NaN ! // cl_float_to_FF(val) wandelt ein IEEE-Single-Float val in ein Single-Float um. ! extern cl_private_thing cl_float_to_FF_pointer (const ffloatjanus& val); ! inline const cl_FF cl_float_to_FF (const ffloatjanus& val) ! { return cl_float_to_FF_pointer(val); } // cl_FF_to_float(obj,&val); // wandelt ein Single-Float obj in ein IEEE-Single-Float val um. --- 237,244 ---- // e=255, m=0: vorzeichenbehaftete Infinity // e=255, m/=0: NaN ! // cl_float_to_FF_pointer(val) wandelt ein IEEE-Single-Float val in ein Single-Float um. ! extern cl_private_thing cl_float_to_FF_pointer (const float val); // cl_FF_to_float(obj,&val); // wandelt ein Single-Float obj in ein IEEE-Single-Float val um. diff -c -3 -r1.4 cl_FF_from_float.cc *** cln/src/float/ffloat/conv/cl_FF_from_float.cc 15 Sep 2007 21:34:16 -0000 1.4 --- cln/src/float/ffloat/conv/cl_FF_from_float.cc 21 Jan 2008 09:39:06 -0000 *************** *** 1,4 **** ! // cl_float_to_FF(). // General includes. #include "cl_sysdep.h" --- 1,7 ---- ! // cl_float_to_FF_pointer(). ! ! // Ensure that union ffloatjanus has a 'float' alternative. ! #define FAST_FLOAT // General includes. #include "cl_sysdep.h" *************** *** 10,17 **** // Implementation. ! cl_private_thing cl_float_to_FF_pointer (const ffloatjanus& val_) { var ffloat val = val_.eksplicit; var uintL exp = (val >> FF_mant_len) & (bit(FF_exp_len)-1); // e if (exp == 0) // e=0 ? --- 13,22 ---- // Implementation. ! cl_private_thing cl_float_to_FF_pointer (const float x) { + var union ffloatjanus val_; + val_.machine_float = x; var ffloat val = val_.eksplicit; var uintL exp = (val >> FF_mant_len) & (bit(FF_exp_len)-1); // e if (exp == 0) // e=0 ? diff -c -3 -r1.4 cl_LF_impl.h *** cln/src/float/lfloat/cl_LF_impl.h 15 Sep 2007 21:34:16 -0000 1.4 --- cln/src/float/lfloat/cl_LF_impl.h 21 Jan 2008 09:39:06 -0000 *************** *** 68,74 **** { var Lfloat _x = TheLfloat(obj); \ var uintE uexp = _x->expo; \ if (uexp==0) \ ! { mantlen_zuweisung _x->len; zero_statement } /* e=0 -> Zahl 0.0 */\ else \ { exp_zuweisung (sintE)(uexp - LF_exp_mid); /* Exponent */ \ sign_zuweisung _x->sign; /* Vorzeichen */\ --- 68,74 ---- { var Lfloat _x = TheLfloat(obj); \ var uintE uexp = _x->expo; \ if (uexp==0) \ ! { unused (mantlen_zuweisung _x->len); zero_statement } /* e=0 -> Zahl 0.0 */\ else \ { exp_zuweisung (sintE)(uexp - LF_exp_mid); /* Exponent */ \ sign_zuweisung _x->sign; /* Vorzeichen */\ diff -c -3 -r1.8 cl_LF_zeta_int.cc *** cln/src/float/transcendental/cl_LF_zeta_int.cc 11 Jan 2008 16:50:15 -0000 1.8 --- cln/src/float/transcendental/cl_LF_zeta_int.cc 21 Jan 2008 09:39:07 -0000 *************** *** 94,100 **** // evaluated using the binary splitting algorithm with truncation. var uintC actuallen = len+2; // 2 guard digits var uintC N = (uintC)(0.39321985*intDsize*actuallen)+1; - var uintC n; struct rational_series_stream : cl_pqd_series_stream { uintC n; int s; --- 94,99 ----
Bruno Haible wrote:
Alexei Sheplyakov wrote:
I'm not sure if CLN code is safe to compile with plain -O2.
With CXXFLAGS="-m64 -O2 -Wall -march=k8 -finline-limit=2000" I get tons of warnings like
../../include/cln/number.h: In constructor 'cln::cl_number::cl_number(float)': ../../include/cln/number.h:238: warning: type-punning to incomplete type might break strict-aliasing rules ../../include/cln/number.h: In member function 'cln::cl_number& cln::cl_number::operator=(float)': ../../include/cln/number.h:238: warning: type-punning to incomplete type might break strict-aliasing rules ../../include/cln/number.h: In constructor 'cln::cl_number::cl_number(double)': ../../include/cln/number.h:239: warning: type-punning to incomplete type might break strict-aliasing rules
Just for the record, I use g++-4.1 (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21).
Attached is a proposed patch that removes most of the warnings. They cause two additional instructions to be added to the functions cl_float_to_FF_pointer and cl_double_to_DF_pointer, but this is worth the gain of being able to compile cln with -O2 with modern gcc. Richy, ok to apply?
Is this a technical question about CVS management? If so, sure, check it in on the main branch, please! Thanks.
Jörg Arndt wrote:
(2) no warnings!, I suggest to use -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused \ -Wshadow -Wundef
While I agree that -Wall is generally useful, and -W is sometimes useful, the others spew too many warnings on perfectly valid code, IMO. Your mileage might vary, of course.
I fully agree. Cruel flamewars have been fought about eradicating or not compiler warnings in application code. This one still makes me shiver: <http://www.ginac.de/pipermail/ginac-devel/2002-September/thread.html#475>. Well, we don't have problems with -Wundef and -Wunused. (Except that older versions of GCC appear not to know about Alexei's newly introduced flatten attribute: float/dfloat/division/cl_DF_fceil.cc:21: warning: `flatten' attribute directive ignored.) -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello! On Tue, Jan 22, 2008 at 12:42:01AM +0100, Richard B. Kreckel wrote:
Well, we don't have problems with -Wundef and -Wunused.
(Except that older versions of GCC appear not to know about Alexei's newly introduced flatten attribute: float/dfloat/division/cl_DF_fceil.cc:21: warning: `flatten' attribute directive ignored.)
--- src/base/cl_maybe_inline.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/base/cl_maybe_inline.h b/src/base/cl_maybe_inline.h index 316cc5b..adcd904 100644 --- a/src/base/cl_maybe_inline.h +++ b/src/base/cl_maybe_inline.h @@ -100,7 +100,7 @@ * a function. * 2. It's ignored if the optimization is switched off. */ -#ifdef __GNUC__ +#if defined(__GNUC__) && ((__GNUC__ > 4) || ((__GNUC__ == 4) && __GNUC__MINOR__ >= 1)) #define CL_FLATTEN __attribute__((flatten)) #else #define CL_FLATTEN -- 1.5.3.7 Best regards, Alexei -- All science is either physics or stamp collecting.
Hi! Alexei Sheplyakov wrote:
--- src/base/cl_maybe_inline.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/base/cl_maybe_inline.h b/src/base/cl_maybe_inline.h index 316cc5b..adcd904 100644 --- a/src/base/cl_maybe_inline.h +++ b/src/base/cl_maybe_inline.h @@ -100,7 +100,7 @@ * a function. * 2. It's ignored if the optimization is switched off. */ -#ifdef __GNUC__ +#if defined(__GNUC__) && ((__GNUC__ > 4) || ((__GNUC__ == 4) && __GNUC__MINOR__ >= 1)) #define CL_FLATTEN __attribute__((flatten)) #else #define CL_FLATTEN
Thank you, Alexei. I've committed a feature-based test for that attribute to avoid the warning. Now to something completely different: I got access to a bigger machine and found new bugs in the output routine there. So, I'll release CLN-1.2.1 shortly. This is a good time to try current CVS, if people feel bored. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello Richard, * Richard B. Kreckel wrote on Sat, Feb 09, 2008 at 06:04:33PM CET:
Now to something completely different: I got access to a bigger machine and found new bugs in the output routine there. So, I'll release CLN-1.2.1 shortly. This is a good time to try current CVS, if people feel bored.
You could update m4/libtool.m4 from Libtool 1.5.26. It fixes a couple of minor bugs your users might encounter, and a couple of misnamed cache variables that the next Autoconf release will warn about. Cheers, Ralf
Hi! Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Sat, Feb 09, 2008 at 06:11:09PM CET:
You could update m4/libtool.m4 from Libtool 1.5.26
and autoconf/ltmain.sh, of course, sorry about that.
Okay, done. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Dear Richard, On Sat, Feb 09, 2008 at 06:04:33PM +0100, Richard B. Kreckel wrote:
I've committed a feature-based test for that attribute to avoid the warning.
Just a small correction: diff --git a/src/base/cl_maybe_inline.h b/src/base/cl_maybe_inline.h index 4f7a982..9d185f4 100644 --- a/src/base/cl_maybe_inline.h +++ b/src/base/cl_maybe_inline.h @@ -102,7 +102,7 @@ * a function. * 2. It's ignored if the optimization is switched off. */ -#if defined(__GNUC__) && defined(CL_ATTRIBUTE_FLATTEN) +#if defined(__GNUC__) && defined(CL_HAVE_ATTRIBUTE_FLATTEN) #define CL_FLATTEN __attribute__((flatten)) #else #define CL_FLATTEN Best regards, Alexei -- All science is either physics or stamp collecting.
Alexei Sheplyakov wrote:
Just a small correction:
diff --git a/src/base/cl_maybe_inline.h b/src/base/cl_maybe_inline.h index 4f7a982..9d185f4 100644 --- a/src/base/cl_maybe_inline.h +++ b/src/base/cl_maybe_inline.h @@ -102,7 +102,7 @@ * a function. * 2. It's ignored if the optimization is switched off. */ -#if defined(__GNUC__) && defined(CL_ATTRIBUTE_FLATTEN) +#if defined(__GNUC__) && defined(CL_HAVE_ATTRIBUTE_FLATTEN) #define CL_FLATTEN __attribute__((flatten)) #else #define CL_FLATTEN
D'oh! Thank you. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Bruno Haible <bruno@clisp.org> [Jan 22. 2008 13:05]:
[...] Attached is a proposed patch that removes most of the warnings. They cause two additional instructions to be added to the functions cl_float_to_FF_pointer and cl_double_to_DF_pointer, but this is worth the gain of being able to compile cln with -O2 with modern gcc. Richy, ok to apply?
Thanks a lot!
Hi Jörg! Joerg Arndt wrote:
Congratulations!
Thank you.
builds and checks fine with openSUSE 10.3 (X86-64)
Can't you add it to the next openSUSE, together with GiNaC, please? It was so annoying when I upgraded my machine at work to openSUSE 10.2 and found that the only reasonably usable calculator (ginsh) has disappeared. And how can you live without that pi program?
May I suggest to add a AGM based pi-computation?
Well, patches are very welcome! ;-)
Two observations: by default you use (1) only -O, I suggest to use -O2 (but not -O3).
We encourage people to export CXXFLAGS!
(2) no warnings!, I suggest to use -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused \ -Wshadow -Wundef ... and -Werror if you are daring ... valgrind for further headaches ;-)
:) -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi richy, * Richard B. Kreckel <kreckel@ginac.de> [Jan 21. 2008 12:35]:
Hi Jörg!
Joerg Arndt wrote:
Congratulations!
Thank you.
builds and checks fine with openSUSE 10.3 (X86-64)
Can't you add it to the next openSUSE, together with GiNaC, please? It was so annoying when I upgraded my machine at work to openSUSE 10.2 and found that the only reasonably usable calculator (ginsh) has disappeared. And how can you live without that pi program?
I am not with SuSE anymore, I now live in Australia doing my PhD. The reasons that the CLN and GiNaC packages were a bit of a maintenance nightmare were the things I mentioned in the mail before. These suggestions should be seriously considered. Most fixes we needed were so tricky that I had to bother the compiler folks pretty much constantly! Btw. openSUSE 10.3 is IMO the first "good" version since 9.3 (to which I was stuck for technical reasons (benchmarks with my fxtbook project)). You might want to give it a try. I know it has CLN packaged, didn't check for GiNaC. The openSUSE project has a build service: you can try to build it and get all the interesting messages first hand 8-))
May I suggest to add a AGM based pi-computation?
Well, patches are very welcome! ;-)
I'll give it a try. Here is why I suggested it: Some people compare performance of Pi computations ignoring that one is AGM based and another is binsplit based. Having both gives a good impression on the performance of these two fundamentally different (and fundamentally important) algorithms.
Two observations: by default you use (1) only -O, I suggest to use -O2 (but not -O3).
We encourage people to export CXXFLAGS!
I'll try -O2 (and possibly -O3) ASAP (which may not be soon at all).
(2) no warnings!, I suggest to use -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused \ -Wshadow -Wundef ... and -Werror if you are daring ... valgrind for further headaches ;-)
:)
(see other mail).
-richy. --
cheers, jj
Dear Jörg, Joerg Arndt wrote:
The reasons that the CLN and GiNaC packages were a bit of a maintenance nightmare were the things I mentioned in the mail before. These suggestions should be seriously considered. Most fixes we needed were so tricky that I had to bother the compiler folks pretty much constantly!
What reasons in that other mail explain why CLN or GiNaC were or are a maintenance nightmare? They compile out of the box using GCC, they pass make check, install cleanly and generally work. If not, why not send a bug report? I hope you don't mean failing to compile with -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused -Wshadow -Wundef -Werror. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Richard B. Kreckel <kreckel@ginac.de> [Jan 22. 2008 13:07]:
Dear Jörg,
Joerg Arndt wrote:
The reasons that the CLN and GiNaC packages were a bit of a maintenance nightmare were the things I mentioned in the mail before. These suggestions should be seriously considered. Most fixes we needed were so tricky that I had to bother the compiler folks pretty much constantly!
What reasons in that other mail explain why CLN or GiNaC were or are a maintenance nightmare? They compile out of the box using GCC, they pass make check, install cleanly and generally work. If not, why not send a bug report?
I hope you don't mean failing to compile with -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused -Wshadow -Wundef -Werror.
No, IIRC the issues were with strict aliasing (and, IIRC(2) something with initialization order, I think we had a discussion back then). The compiler messages often left me clueless and only the compiler people could point me to the underlying issues. IIRC(3) the itanium arch was the worst and IIRC(4) we tagged CLN etc as DOES_NOT_BUILD on the arch because nobody was much interested in fixing there.
Cheers -richy.
regards, jj
Hello! On Tue, Jan 22, 2008 at 05:24:36PM +1100, Joerg Arndt wrote:
IIRC(3) the itanium arch was the worst and IIRC(4) we tagged CLN etc as DOES_NOT_BUILD on the arch because nobody was much interested in fixing there.
Interesting. According to http://buildd.debian.org/build.cgi?pkg=cln CLN happens to (auto-)build on ia64. There was a couple of failures, but I guess that's very far from DOES_NOT_BUILD. That said, I have no itanium boxes there, so I can't check if there are some runtime errors. Best regards, Alexei -- All science is either physics or stamp collecting.
How do you force CLN to build in 64-bit mode? None of the "obvious" things I tried worked (e.g. ./configure --build=x86_64, CFLAGS=-m64 CXXFLAGS=-m64 ./configure). rg On Jan 22, 2008, at 2:40 AM, Alexei Sheplyakov wrote:
Hello!
On Tue, Jan 22, 2008 at 05:24:36PM +1100, Joerg Arndt wrote:
IIRC(3) the itanium arch was the worst and IIRC(4) we tagged CLN etc as DOES_NOT_BUILD on the arch because nobody was much interested in fixing there.
Interesting. According to
http://buildd.debian.org/build.cgi?pkg=cln
CLN happens to (auto-)build on ia64. There was a couple of failures, but I guess that's very far from DOES_NOT_BUILD. That said, I have no itanium boxes there, so I can't check if there are some runtime errors.
Best regards, Alexei
-- All science is either physics or stamp collecting.
_______________________________________________ CLN-list mailing list CLN-list@ginac.de https://www.cebix.net/mailman/listinfo/cln-list
Ron Garret wrote:
How do you force CLN to build in 64-bit mode? None of the "obvious" things I tried worked (e.g. ./configure --build=x86_64, CFLAGS=-m64 CXXFLAGS=-m64 ./configure).
The autoconf documentation [1], section "Preset Output Variables", says: "If an option affects multiple phases of the compiler, though, matters get tricky. One approach to put such options directly into @code{CC}, e.g., @code{CC='gcc -m64'}. Another is to put them into both @code{CPPFLAGS} and @code{LDFLAGS}, but not into @code{CFLAGS}." The first approach: $ export CC="gcc -m64" CXX="g++ -m64" $ ./configure The second approach: $ export CPPFLAGS=-m64 CFLAGS="-O" CXXFLAGS="-O" LDFLAGS=-m64 $ ./configure The third approach (a little safer than the second): $ export CPPFLAGS=-m64 CFLAGS="-m64 -O" CXXFLAGS="-m64 -O" LDFLAGS=-m64 $ ./configure All three work. Tested on Linux/x86_64. Bruno [1] http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=doc/autoconf.tex...
Hello! On Tue, Jan 22, 2008 at 02:26:20PM -0800, Ron Garret wrote:
How do you force CLN to build in 64-bit mode?
It's the default on my platform (GNU/Linux/amd64).
None of the "obvious" things I tried worked (e.g. ./configure --build=x86_64
This "obvious" way is plain wrong. First, --build means: `--build=BUILD-TYPE' the type of system on which the package is being configured and compiled. So, setting this is pointless, unless you also set --host. Secondly, the value `x86_64' is wrong. It should be CPU-OS-VENDOR. On GNU/Linux/amd64 it's x86_64-linux-gnu (or something like that).
CFLAGS=-m64 CXXFLAGS=-m64 ./configure
This one should work. If not, set --host AND --build (host == build, otherwise autoconf will think you are cross compiling and will get it wrong). Unfortunately, I don't know that magic string for your OS. Best regards, Alexei -- All science is either physics or stamp collecting.
Hi! Alexei Sheplyakov wrote:
On Tue, Jan 22, 2008 at 02:26:20PM -0800, Ron Garret wrote:
How do you force CLN to build in 64-bit mode?
It's the default on my platform (GNU/Linux/amd64).
None of the "obvious" things I tried worked (e.g. ./configure --build=x86_64
This "obvious" way is plain wrong. First, --build means:
`--build=BUILD-TYPE' the type of system on which the package is being configured and compiled.
So, setting this is pointless, unless you also set --host.
Secondly, the value `x86_64' is wrong. It should be CPU-OS-VENDOR. On GNU/Linux/amd64 it's x86_64-linux-gnu (or something like that).
CFLAGS=-m64 CXXFLAGS=-m64 ./configure
This one should work.
But it would fail to turn on optimization. So, better like: CFLAGS="-m64 -O" CXXFLAGS="-m64 -O" ./configure Regarding the __i386__ definition: There is code in m4/general.m4 that ought to correct the misleading uname -m output if kernelland is 64 bit and userland 32 bit. It's worked for others so far. Why does it fail for Ron? -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello! On Wed, Jan 23, 2008 at 08:07:48AM +0100, Richard B. Kreckel wrote:
Regarding the __i386__ definition: There is code in m4/general.m4 that ought to correct the misleading uname -m output if kernelland is 64 bit and userland 32 bit.
The userland (on OS X) is not 32-bit, it's biarch.
It's worked for others so far.
Not exactly. Attempt to built 32-bit CLN on biarch GNU/Linux/amd64 system fails too. Although the problem is different here. The compilation log, config.log, and include/cln/config.h can be found here: http://theor.jinr.ru/~varg/web/misc/cln-1.2.0-32bit-on-amd64.tar.bz2
Why does it fail for Ron?
Because the kernel and userland are biarch, and
[ron@mickey:~]$ uname -m i386
Best regards, Alexei -- All science is either physics or stamp collecting.
Richard B. Kreckel wrote:
Regarding the __i386__ definition: There is code in m4/general.m4 that ought to correct the misleading uname -m output if kernelland is 64 bit and userland 32 bit. It's worked for others so far. Why does it fail for Ron?
It fails for Ron because his 'uname -m' result does not indicate a 64-bit CPU. This should fix it. Committed. 2007-01-23 Bruno Haible <bruno@clisp.org> Allow 64-bit builds on MacOS X 10.5. * m4/general.m4 (CL_CANONICAL_HOST_CPU): Test for x86_64 CPU if "uname -m" returns "i386". Reported by Ron Garret <ron@flownet.com>. *** m4/general.m4 18 Dec 2007 23:01:19 -0000 1.4 --- m4/general.m4 23 Jan 2008 12:05:00 -0000 *************** *** 1,4 **** ! dnl Copyright (C) 1993-2006 Free Software Foundation, Inc. dnl This file is free software, distributed under the terms of the GNU dnl General Public License. As a special exception to the GNU General dnl Public License, this file may be distributed as part of a program --- 1,4 ---- ! dnl Copyright (C) 1993-2008 Free Software Foundation, Inc. dnl This file is free software, distributed under the terms of the GNU dnl General Public License. As a special exception to the GNU General dnl Public License, this file may be distributed as part of a program *************** *** 184,192 **** host_cpu=sparc fi ;; dnl AMD64 running Linux have 'uname -m' = "x86_64" even if userland is purely dnl 32-bit. ! x86_64 ) AC_CACHE_CHECK([for 64-bit userland on x86-64], cl_cv_host_x86_64, [ AC_COMPILE_IFELSE([AC_LANG_PROGRAM( [[#if !defined __x86_64__ --- 184,194 ---- host_cpu=sparc fi ;; + dnl MacOS X 10.5 machines on x86_64 platforms have 'uname -m' = "i386" even + dnl if 64-bit programs are fully supported. dnl AMD64 running Linux have 'uname -m' = "x86_64" even if userland is purely dnl 32-bit. ! i386 | x86_64 ) AC_CACHE_CHECK([for 64-bit userland on x86-64], cl_cv_host_x86_64, [ AC_COMPILE_IFELSE([AC_LANG_PROGRAM( [[#if !defined __x86_64__
On Jan 22, 2008, at 10:49 PM, Alexei Sheplyakov wrote:
Hello!
On Tue, Jan 22, 2008 at 02:26:20PM -0800, Ron Garret wrote:
How do you force CLN to build in 64-bit mode?
It's the default on my platform (GNU/Linux/amd64).
None of the "obvious" things I tried worked (e.g. ./configure --build=x86_64
This "obvious" way is plain wrong. First, --build means:
`--build=BUILD-TYPE' the type of system on which the package is being configured and compiled.
So, setting this is pointless, unless you also set --host.
I tried that too. No joy.
Secondly, the value `x86_64' is wrong. It should be CPU-OS-VENDOR. On GNU/Linux/amd64 it's x86_64-linux-gnu (or something like that).
I tried x86_64-darwin-apple and x86_64-osx-apple. Configure didn't like either one. checking build system type... Invalid configuration `x86_64-osx- apple': machine `x86_64-osx-apple' not recognized configure: error: /bin/sh ./autoconf/config.sub x86_64-osx-apple failed checking build system type... Invalid configuration `x86_64-darwin- apple': machine `x86_64-darwin-apple' not recognized configure: error: /bin/sh ./autoconf/config.sub x86_64-darwin-apple failed
CFLAGS=-m64 CXXFLAGS=-m64 ./configure
This one should work.
That's what I thought.
If not, set --host AND --build (host == build, otherwise autoconf will think you are cross compiling and will get it wrong). Unfortunately, I don't know that magic string for your OS.
That makes two of us then. rg
On Tue, Jan 22, 2008 at 11:34:08PM -0800, Ron Garret wrote:
If not, set --host AND --build (host == build, otherwise autoconf will think you are cross compiling and will get it wrong). Unfortunately, I don't know that magic string for your OS.
That makes two of us then.
Apparently it's x86_64-apple-darwin. So, try ./configure --host=x86_64-apple-darwin --build=x86_64-apple-darwind Hope that helps, Alexei -- All science is either physics or stamp collecting.
Alexei Sheplyakov wrote:
Apparently it's x86_64-apple-darwin. So, try
./configure --host=x86_64-apple-darwin --build=x86_64-apple-darwin
Then it could be a config.guess bug. Ron, can you tell us a bit more? 1) Can your system actually execute 64-bit programs? $ echo > hello.c <<\EOF #include <stdio.h> int main () { printf("Hello, world.\n"); return 0; } $ gcc -m64 hello.c $ ./a.out 2) What does config.guess return when you run it like this? $ export CC="gcc -m64" $ sh autoconf/config.guess Bruno
Alexei Sheplyakov wrote:
Secondly, the value `x86_64' is wrong. It should be CPU-OS-VENDOR.
No, it's usually CPU-VENDOR-OS, or (in the cases where RMS wants to see "gnu" mentioned) CPU-VENDOR-KERNEL-OS. This is described at the top of the config.sub file. Bruno
On Jan 23, 2008, at 4:12 AM, Bruno Haible wrote:
Alexei Sheplyakov wrote:
Secondly, the value `x86_64' is wrong. It should be CPU-OS-VENDOR.
No, it's usually CPU-VENDOR-OS,
Well, x86_64-apple-darwin doesn't work either, but it's a different error this time, so maybe this is progress: cd src && make all make SUBDIR=base /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include - I./base -c ./base/cl_alloca.cc mkdir .libs g++ -O -I../include -I../include -I./base -c ./base/cl_alloca.cc - fno-common -DPIC -o .libs/cl_alloca.o g++ -O -I../include -I../include -I./base -c ./base/cl_alloca.cc -o cl_alloca.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include - I./base -c ./base/cl_as_exception.cc g++ -O -I../include -I../include -I./base -c ./base/ cl_as_exception.cc -fno-common -DPIC -o .libs/cl_as_exception.o In file included from ../include/cln/number.h:8, from ./base/cl_N.h:6, from ./base/cl_as_exception.cc:13: ../include/cln/object.h:29:1: warning: "cl_word_alignment" redefined ../include/cln/object.h:26:1: warning: this is the location of the previous definition ../include/cln/number.h: In constructor 'cln::cl_number::cl_number()': ../include/cln/number.h:226: error: 'cl_FN_tag' was not declared in this scope ../include/cln/number.h: In constructor 'cln::cl_number::cl_number(int)': ../include/cln/number.h:230: error: 'cl_FN_tag' was not declared in this scope ../include/cln/number.h: In constructor 'cln::cl_number::cl_number(unsigned int)': ../include/cln/number.h:230: error: 'cl_FN_tag' was not declared in this scope ../include/cln/number.h: In member function 'cln::cl_number& cln::cl_number::operator=(int)': ../include/cln/number.h:231: error: 'cl_FN_tag' was not declared in this scope ../include/cln/number.h: In member function 'cln::cl_number& cln::cl_number::operator=(unsigned int)': ../include/cln/number.h:231: error: 'cl_FN_tag' was not declared in this scope make[2]: *** [cl_as_exception.lo] Error 1 make[1]: *** [base.target] Error 2 make: *** [all] Error 2
BTW, I still get this error even with Bruno's patch to general.m4 applied. BTW2, with Bruno's patch applied, ./configure;make fails on base/ digitseq/cl_asm.s in the same way as before. Also, this just makes it compile 64-bit by default, which is probably not the Right Thing. rg On Jan 23, 2008, at 8:23 AM, Ron Garret wrote:
On Jan 23, 2008, at 4:12 AM, Bruno Haible wrote:
Alexei Sheplyakov wrote:
Secondly, the value `x86_64' is wrong. It should be CPU-OS-VENDOR.
No, it's usually CPU-VENDOR-OS,
Well, x86_64-apple-darwin doesn't work either, but it's a different error this time, so maybe this is progress:
cd src && make all make SUBDIR=base /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include - I./base -c ./base/cl_alloca.cc mkdir .libs g++ -O -I../include -I../include -I./base -c ./base/cl_alloca.cc - fno-common -DPIC -o .libs/cl_alloca.o g++ -O -I../include -I../include -I./base -c ./base/cl_alloca.cc -o cl_alloca.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile g++ -O -I../include -I../include - I./base -c ./base/cl_as_exception.cc g++ -O -I../include -I../include -I./base -c ./base/ cl_as_exception.cc -fno-common -DPIC -o .libs/cl_as_exception.o In file included from ../include/cln/number.h:8, from ./base/cl_N.h:6, from ./base/cl_as_exception.cc:13: ../include/cln/object.h:29:1: warning: "cl_word_alignment" redefined ../include/cln/object.h:26:1: warning: this is the location of the previous definition ../include/cln/number.h: In constructor 'cln::cl_number::cl_number()': ../include/cln/number.h:226: error: 'cl_FN_tag' was not declared in this scope ../include/cln/number.h: In constructor 'cln::cl_number::cl_number(int)': ../include/cln/number.h:230: error: 'cl_FN_tag' was not declared in this scope ../include/cln/number.h: In constructor 'cln::cl_number::cl_number(unsigned int)': ../include/cln/number.h:230: error: 'cl_FN_tag' was not declared in this scope ../include/cln/number.h: In member function 'cln::cl_number& cln::cl_number::operator=(int)': ../include/cln/number.h:231: error: 'cl_FN_tag' was not declared in this scope ../include/cln/number.h: In member function 'cln::cl_number& cln::cl_number::operator=(unsigned int)': ../include/cln/number.h:231: error: 'cl_FN_tag' was not declared in this scope make[2]: *** [cl_as_exception.lo] Error 1 make[1]: *** [base.target] Error 2 make: *** [all] Error 2
_______________________________________________ CLN-list mailing list CLN-list@ginac.de https://www.cebix.net/mailman/listinfo/cln-list
On Wed, Jan 23, 2008 at 08:33:43AM -0800, Ron Garret wrote:
BTW, I still get this error even with Bruno's patch to general.m4 applied.
May be you've forgotten to re-generate the configure script?
BTW2, with Bruno's patch applied, ./configure;make fails on base/ digitseq/cl_asm.s in the same way as before.
Also, this just makes it compile 64-bit by default,
Not really. You still need to (manually) set CXXFLAGS and CFLAGS.
which is probably not the Right Thing.
Some people (including myself) would argue that compiling 32-bit by default is not the Right Thing in general and even more wrong for CLN. Best regards, Alexei -- All science is either physics or stamp collecting.
On Wed, Jan 23, 2008 at 08:23:46AM -0800, Ron Garret wrote:
Well, x86_64-apple-darwin doesn't work either, but it's a different error this time, so maybe this is progress: [skipped the error messages]
I'm afraid it is not. Configure got confused in another way. For some reason it decided to use plain g++ instead of x86_64-apple-darwin (autoconf expects it to produce 64-bit code, i.e. even without -m64 switch). But g++ generates 32-bit code, while some configure-generated headers are intended for 64-bit one. So, the next incantation to try is ./configure --host=x86_64-apple-darwin --build=x86_64-apple-darwin CXXFLAGS='-O -m64' CFLAGS='-O -m64' Hope this *really* helps, Alexei -- All science is either physics or stamp collecting.
On Jan 23, 2008, at 9:09 AM, Alexei Sheplyakov wrote:
On Wed, Jan 23, 2008 at 08:23:46AM -0800, Ron Garret wrote:
Well, x86_64-apple-darwin doesn't work either, but it's a different error this time, so maybe this is progress: [skipped the error messages]
I'm afraid it is not. Configure got confused in another way. For some reason it decided to use plain g++ instead of x86_64-apple-darwin (autoconf expects it to produce 64-bit code, i.e. even without -m64 switch). But g++ generates 32-bit code, while some configure-generated headers are intended for 64-bit one. So, the next incantation to try is
./configure --host=x86_64-apple-darwin --build=x86_64-apple-darwin CXXFLAGS='-O -m64' CFLAGS='-O -m64'
Hope this *really* helps,
Almost. Needed to add LDFLAGS=-m64. Then it worked. Woohoo! rg
Ron Garret wrote:
On Jan 23, 2008, at 9:09 AM, Alexei Sheplyakov wrote:
On Wed, Jan 23, 2008 at 08:23:46AM -0800, Ron Garret wrote:
Well, x86_64-apple-darwin doesn't work either, but it's a different error this time, so maybe this is progress: [skipped the error messages]
I'm afraid it is not. Configure got confused in another way. For some reason it decided to use plain g++ instead of x86_64-apple-darwin (autoconf expects it to produce 64-bit code, i.e. even without -m64 switch). But g++ generates 32-bit code, while some configure-generated headers are intended for 64-bit one. So, the next incantation to try is
./configure --host=x86_64-apple-darwin --build=x86_64-apple-darwin CXXFLAGS='-O -m64' CFLAGS='-O -m64'
Hope this *really* helps,
Almost. Needed to add LDFLAGS=-m64. Then it worked. Woohoo!
Woohoo! That leaves me wonder if there's something to fix to make it work better next time someone gives it a try. Does anyone know? Frankly, I'm lost. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Jan 27, 2008, at 7:32 AM, Richard B. Kreckel wrote:
Ron Garret wrote:
On Jan 23, 2008, at 9:09 AM, Alexei Sheplyakov wrote:
On Wed, Jan 23, 2008 at 08:23:46AM -0800, Ron Garret wrote:
Well, x86_64-apple-darwin doesn't work either, but it's a different error this time, so maybe this is progress: [skipped the error messages]
I'm afraid it is not. Configure got confused in another way. For some reason it decided to use plain g++ instead of x86_64-apple-darwin (autoconf expects it to produce 64-bit code, i.e. even without -m64 switch). But g++ generates 32-bit code, while some configure-generated headers are intended for 64-bit one. So, the next incantation to try is
./configure --host=x86_64-apple-darwin --build=x86_64-apple-darwin CXXFLAGS='-O -m64' CFLAGS='-O -m64'
Hope this *really* helps,
Almost. Needed to add LDFLAGS=-m64. Then it worked. Woohoo!
Woohoo!
That leaves me wonder if there's something to fix to make it work better next time someone gives it a try. Does anyone know? Frankly, I'm lost.
There's a spirited discussion about that very topic underway on the bug-gnulib list. The issue is still unresolved. In the meantime, I would suggest adding some verbiage to the INSTALL file. (While we're at it, it might be good to figure out how to build a fat binary. I've never done it before so I don't have a clue. Do you have to build the whole thing twice? Is there a -m32/64 flag?) rg
Hi! Joerg Arndt wrote:
* Richard B. Kreckel <kreckel@ginac.de> [Jan 22. 2008 13:07]:
What reasons in that other mail explain why CLN or GiNaC were or are a maintenance nightmare? They compile out of the box using GCC, they pass make check, install cleanly and generally work. If not, why not send a bug report?
I hope you don't mean failing to compile with -W -Wall -Wconversion -Wsign-promo -Wsign-compare -Wunused -Wshadow -Wundef -Werror.
No, IIRC the issues were with strict aliasing (and, IIRC(2) something with initialization order, I think we had a discussion back then). The compiler messages often left me clueless and only the compiler people could point me to the underlying issues.
IIRC(3) the itanium arch was the worst and IIRC(4) we tagged CLN etc as DOES_NOT_BUILD on the arch because nobody was much interested in fixing there.
Well, that is long ago and I can assure that all those issues have long been fixed. Alexei already pointed to the Debian build log and if you browse through it, you'll see that it actually executes make check. Also, I've used CLN personally on Itanic machines. In 2001/2002, some nice folks at SuSE helped with little patches and, sometimes, even with access to non-mainstream machines. But in 2004, I got some broken patches for old versions of CLN that fixed issues that had long been fixed in my official releases. Apparently, somebody unexperienced there had tried to do some wild fixing. But, as I said, those issues have been resolved. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Joerg Arndt wrote:
May I suggest to add a AGM based pi-computation? Well, patches are very welcome! ;-)
I'll give it a try.
Here is why I suggested it: Some people compare performance of Pi computations ignoring that one is AGM based and another is binsplit based. Having both gives a good impression on the performance of these two fundamentally different (and fundamentally important) algorithms.
Good idea. Where, approximately, do you expect a break-even to occur? Should we make bets? -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Richard B. Kreckel <kreckel@ginac.de> [Jan 22. 2008 13:08]:
Joerg Arndt wrote:
May I suggest to add a AGM based pi-computation? Well, patches are very welcome! ;-) I'll give it a try. Here is why I suggested it: Some people compare performance of Pi computations ignoring that one is AGM based and another is binsplit based. Having both gives a good impression on the performance of these two fundamentally different (and fundamentally important) algorithms.
Good idea. Where, approximately, do you expect a break-even to occur? Should we make bets?
binsplit wins routinely whenever applicable, mostly for its memory locality. There are, however, things where (to my knowledge) no binsplit based algorithm can be used. So it is fine to also know about the performance of the AGM. No bets, but you may want to smash 15 secs (AGM!) for 1 mio digits of Pi (hfloat, after 50% speedup with recursive FHT, see fxtbook if not yet there in CLN). AGM based algorithms spent >95% (sometimes 99%) in the transforms so you do get a fine impression about your raw multiplication speed (if the AGM is properly done). All assuming you are using very large precisions. Only if you know your code very well you can make _any_ guess about the speed (and still you might be far off).
-richy.
Btw. example programs make learning easy, especially for people who check the doc only if everything else fails 8-)) If the example programs have a timing mechanism then they are also usable to detect regressions with performance. cheers, jj
Joerg Arndt wrote:
binsplit wins routinely whenever applicable, mostly for its memory locality. There are, however, things where (to my knowledge) no binsplit based algorithm can be used. So it is fine to also know about the performance of the AGM.
To me it looks like the AGM is based on mathematical properties of particular algebraic curves. Whereas binsplit is a general technique that provides fast evaluation of any holonomic function (with algebraic initial conditions at an algebraic point) at regular and even at singular points. These are resuls from Joris van der Hoeven [1] (see the three papers Fast evaluation of holonomic functions Fast evaluation of holonomic functions near and in singularities Efficient accelero-summation of holonomic functions there). Bruno [1] http://www.math.u-psud.fr/~vdhoeven/
* Bruno Haible <bruno@clisp.org> [Jan 23. 2008 14:14]:
Joerg Arndt wrote:
binsplit wins routinely whenever applicable, mostly for its memory locality. There are, however, things where (to my knowledge) no binsplit based algorithm can be used. So it is fine to also know about the performance of the AGM.
To me it looks like the AGM is based on mathematical properties of particular algebraic curves. Whereas binsplit is a general technique that provides fast evaluation of any holonomic function (with algebraic initial conditions at an algebraic point) at regular and even at singular points. These are resuls from Joris van der Hoeven [1] (see the three papers Fast evaluation of holonomic functions Fast evaluation of holonomic functions near and in singularities Efficient accelero-summation of holonomic functions there).
Bruno
For the computation of a logarithm of a real number (that ist not a rational a/b with both a nd b small) the AGM approach(s) are IIRC the fastest known. I do not see how to use binsplit there but that may just reflect some lack of knowledge on my side. I also did not study the "bit-burst" method so far. regards, jj
Joerg Arndt wrote:
For the computation of a logarithm of a real number (that ist not a rational a/b with both a nd b small) the AGM approach(s) are IIRC the fastest known. I do not see how to use binsplit there
log being the inverse function of exp, a Newton iteration (with increasing precision: precision n for the last iteration, n/2 for the second-to-last, n/4 for the third-to-last etc.) of the equation exp(x) = c will yield log(c). If the computation time for exp is O(n (log n)^j (log log n)^k) (j, k usually being 1 or 2), then the computation time for its inverse function is the same: it differs only by a O(1) factor. This is already contained in Brent's classical paper from the 70ies.
I also did not study the "bit-burst" method so far.
The first part of Paul Zimmermann's presentation on the "bit-burst algorithm" is a reminder to Brent's technique coming from the Newton iteration, as outlined above. Then he applies this technique to holonomic function. I think this is the same idea as in van der Hoeven's paper, presented in a more understandable form (and working with the coefficient recursion instead of the differential equation - you cannot prove much mathematics when working on the coefficient recursion, because you are no longer working in an integral domain, but when it comes to doing the computations, the coefficient recursion side is often a little more efficient than the differential equation side). Bruno
Dear Jörg, Joerg Arndt wrote:
For the computation of a logarithm of a real number (that ist not a rational a/b with both a nd b small) the AGM approach(s) are IIRC the fastest known. I do not see how to use binsplit there but that may just reflect some lack of knowledge on my side.
BTW, I just read what your upcoming book has to say about binary splitting. The section about the memory consumption in "Computation of π: binary splitting versus AGM-type iterations" is too pessimistic. You write: "The drawback of the binary splitting scheme is that it may need significantly more memory than two full words. This may happen if the numerator and denominator grow fast which is more likely if no series so favorable as [Chudnovsky's series for pi] can be used for the quantity to be computed." With the truncation technique I described earlier, the memory needed is basically independent of the series. The growth of numerator and denominator is limited to the precision of the result. The computation of Euler's γ in CLN-1.2.0 is actually an excellent example for this. See the two graphs at [0] and observe that the blue curves' maximum is not so different after all (it peaks at 8.4MiB for π and for 15.6MiB for γ.) What you write is correct without truncation, though. See the red and green curves. Cheers -richy. [0] <http://www.ginac.de/~kreckel/news.html#EulerConstantOneBillionDigits> -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
* Richard B. Kreckel <kreckel@ginac.de> [Jan 26. 2008 17:04]:
[...] With the truncation technique I described earlier, the memory needed is basically independent of the series. The growth of numerator and denominator is limited to the precision of the result. The computation of Euler's γ in CLN-1.2.0 is actually an excellent example for this. See the two graphs at [0] and observe that the blue curves' maximum is not so different after all (it peaks at 8.4MiB for π and for 15.6MiB for γ.) What you write is correct without truncation, though. See the red and green curves.
Oha! I'll update (brain & text), thanks for the input!
Cheers -richy.
[0] <http://www.ginac.de/~kreckel/news.html#EulerConstantOneBillionDigits>
cheers, jj
Hello! On Sat, Jan 19, 2008 at 11:34:24PM +0100, Richard B. Kreckel wrote:
The second reason is that while performing the binary splitting, some intermediate integer results may become much larger than the result's precision warrants. As it turns out, that excess precision can simply be truncated by coercing the result into a cl_LF of appropriate length. Basically, this compresses the extra digits into the floating-point exponent.
Can you prove this won't result in an additional roundoff error?
With some rational series, the savings are dramatic. As an extreme example, attached is a picture of the memory footprint when computing one million decimal digits of Euler's gamma. The red curve corresponds to CLN-1.1.x while the blue one to CLN 1.2.0. Here, making the operands smaller even saves computing time.
What about the accuracy of the result? Best regards, Alexei -- All science is either physics or stamp collecting.
Dear Alexei, Alexei Sheplyakov wrote:
The second reason is that while performing the binary splitting, some intermediate integer results may become much larger than the result's precision warrants. As it turns out, that excess precision can simply be truncated by coercing the result into a cl_LF of appropriate length. Basically, this compresses the extra digits into the floating-point exponent.
Can you prove this won't result in an additional roundoff error?
No. This is a good point and I've been worrying about it, too. Certainly, chopping off precision early may poison the final result – although not too much, because it only occurs on the top few levels of a binary tree! Still, for this reason I've not enabled the truncation by default in all binary splitting routines. It is optional and enabled only when used in certain rational series (Pi, Euler's constant, Catalan's constant, ...) where I paid special attention to the result's accuracy case by case.
With some rational series, the savings are dramatic. As an extreme example, attached is a picture of the memory footprint when computing one million decimal digits of Euler's gamma. The red curve corresponds to CLN-1.1.x while the blue one to CLN 1.2.0. Here, making the operands smaller even saves computing time.
What about the accuracy of the result?
As I mentioned: I've tried thousands of operand sizes from thousands to billions of decimal digits and never seen a difference. It would've been easy to compensate by introducing additional guard digits for instance. But it turned out to be completely unnecessary. What is better: proof or demonstration? :-) Well, I know it may not be completely satisfactory. If someone has a mathematical comprehension of why this is so, please do let me know. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (6)
-
Alexei Sheplyakov
-
Bruno Haible
-
Joerg Arndt
-
Ralf Wildenhues
-
Richard B. Kreckel
-
Ron Garret