- CLN-list - ginac.de

Floating point overflow for cl_R ln (const cl_R& x)
by Johnny Fundalewicz 09 Jan '05

09 Jan '05

Hi, I'm getting some floating point overflow errors when using logarithmic functionc l_R ln (const cl_R& x) with big Numbers ( > 20 Stellen). My code looks like this: -------------------------------- #include <cln/cln.h> int main(){ cln::cl_R number_one = "41234123412341234123157311812341234124312359123412341"; cln::cl_R number_two = cln::ln (number_one); std::cout << number_two << std::endl; return 0; } -------------------------------- I compiled with gcc-Version 3.3.5 (Debian 1:3.3.5-4): g++ -g -o test -lcln test.cpp Have I done a mistake or whats the reason why I can't compute those values - Is the number too large? I'm getting a floating point overflow and my debugger tells about 'Program exited with code 01' Or is there any other solution? Thx, Johnny

2 2

Compilation error:
by Isidro Cachadiña Gutiérrez 14 Dec '04

14 Dec '04

Hi again: Can be overloaded the + and - operators to compile these silly lines: cl_F a,b; a=1*b; a=1/b; and some like these? -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)unex.es * * Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 * *************************************************************************** * Usuario Linux: 8569 * * Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc * ***************************************************************************

2 4

More bugs.
by Isidro Cachadiña Gutiérrez 14 Dec '04

14 Dec '04

Hi again: Another silly program... #include <iostream> #include <cln/lfloat.h> #include <cln/lfloat_io.h> using namespace cln; int main(int argc, char **argv) { default_float_format=float_format(100); cl_LF a,b,c; b="1e-60"; a="1.0"; c=a+b; std::cerr << "c=" << c << std::endl; c=c-a; std::cerr << "c=" << c << std::endl; } And the outputs are 1.0L and 0.0L ¿What happen with the default_float_format?. If I write a="1.00000000000000000000000 ..." (100 zeros here) I obtain the same result, then b is lost somewhere. More, when b about < 1e-20 then it is lost. Maybe an error in the conversion? Bye. -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)unex.es * * Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 * *************************************************************************** * Usuario Linux: 8569 * * Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc * ***************************************************************************

2 6

Re: cln: ungeklärte Probleme (fwd)
by Richard B. Kreckel 10 Dec '04

10 Dec '04

Hi! Ralf: I take this discussion to the mailing list in the hope that somebody there might have an idea. All others: Ralf and I were discussing a small experimental patch (see attachment) that balances all operator new and delete in order to please certain compilers. In particular, I added many no-op operator placement deletes. It also added some unimplemented declarations of private operator delete(void*) member functions to classes that had unimplemented private operator new(size_t). That patch had no effect on the code generated by GCC. However, the Intel compiler complained abaout four missing symbols: On Fri, 3 Dec 2004, Ralf Wildenhues wrote: > * Richard B. Kreckel wrote on Thu, Dec 02, 2004 at 10:17:20PM CET: > > On Thu, 2 Dec 2004, Ralf Wildenhues wrote: > > > cl_SV_ringelt.o: cln::cl_SV_inner<cln::_cl_ring_element>::operator delete(void*) > > > cl_SV_number.o: cln::cl_SV_inner<cln::cl_number>::operator delete(void*) > > > cl_GV_number.o: cln::cl_GV_inner<cln::cl_number>::operator delete(void*) > > > cl_GV_I.o: cln::cl_GV_inner<cln::cl_I>::operator delete(void*) > > > > Bitte schick' mir mal die drei Dateien zum Disassemblen. > > Hier sind die vier. :-) Disassembling the four offending objects established the following (linear) call-graphs (not every symbol could be demangled by GNU objdump): cln::cl_svector_ringelt_destructor(cln::cl_heap*) cln::cl_heap_SV<cln::_cl_ring_element>::~cl_heap_SV() _ZN3cln10cl_heap_SVINS_16_cl_ring_elementEED9Ev cln::cl_SV_inner<cln::_cl_ring_element>::~cl_SV_inner() _ZN3cln11cl_SV_innerINS_16_cl_ring_elementEED9Ev cln::cl_SV_inner<cln::_cl_ring_element>::operator delete(void*) cln::cl_svector_number_destructor(cln::cl_heap*) cln::cl_heap_SV<cln::cl_number>::~cl_heap_SV() _ZN3cln10cl_heap_SVINS_9cl_numberEED9Ev cln::cl_SV_inner<cln::cl_number>::~cl_SV_inner() _ZN3cln11cl_SV_innerINS_9cl_numberEED9Ev cln::cl_SV_inner<cln::cl_number>::operator delete(void*) cln::cl_gvector_number_destructor(cln::cl_heap*) cln::cl_heap_GV<cln::cl_number>::~cl_heap_GV() _ZN3cln10cl_heap_GVINS_9cl_numberEED9Ev cln::cl_GV_inner<cln::cl_number>::~cl_GV_inner() _ZN3cln11cl_GV_innerINS_9cl_numberEED9Ev cln::cl_GV_inner<cln::cl_number>::operator delete(void*) cln::cl_gvector_integer_destructor(cln::cl_heap*) cln::cl_heap_GV<cln::cl_I>::~cl_heap_GV() _ZN3cln10cl_heap_GVINS_4cl_IEED9Ev cln::cl_GV_inner<cln::cl_I>::~cl_GV_inner() _ZN3cln11cl_GV_innerINS_4cl_IEED9Ev cln::cl_GV_inner<cln::cl_I>::operator delete(void*) The pattern is always the same, as is the code that triggers it. For example in cl_GV_I.cc: static void cl_gvector_integer_destructor (cl_heap* pointer) { (*(cl_heap_GV_I*)pointer).~cl_heap_GV_I(); } What I find irritating is that the dtors call their objects' operator delete(void*). Isn't that hazardous? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

3 2

DIGITS
by Isidro Cachadiña Gutiérrez 02 Dec '04

02 Dec '04

Hi all: Are there any way to declare all variables with a number digits for example, something like. funcion_foo (DIGITS); And then you are sure that all floating points variables are of number of decimal digits given by DIGITS. Thanks. -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)unex.es * * Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 * *************************************************************************** * Usuario Linux: 8569 * * Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc * ***************************************************************************

2 4

A silly program
by Isidro Cachadiña Gutiérrez 28 Nov '04

28 Nov '04

Hi All: I don't know if I'm wrong, but why are not defined elsewhere cln::operator-(const float , const cln::cl_R&) and some with double, etc. to compile this silly program. #include <cln/real.h> int main(int argc, char **argv) { cln::cl_F a,b; a=1; b=1.0-a; } -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)unex.es * * Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 * *************************************************************************** * Usuario Linux: 8569 * * Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc * ***************************************************************************

2 4

Types in cl_R
by Isidro Cachadiña Gutiérrez 20 Nov '04

20 Nov '04

Hi All: I am using cln with real numbers. I have a problem in the expt function... Wen I have, for example, #include <cln(/real.h> ... cl_R x,y,z; z=expt(x,y); I have problems with the prototypes defined in <real.h> that causes that expt cannot be used in this way. I also can define this function as: cln::cl_R expt(cln::cl_R x, cln::cl_R y) { return exp(x*ln(y)); } And It works fine, but I think that It have to be defined somewhere in the library. Cheers. -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)unex.es * * Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 * *************************************************************************** * Usuario Linux: 8569 * * Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc * ***************************************************************************

3 6

Re: [CLN-list] make failed on .libs/exam
by werner 05 Nov '04

05 Nov '04

ralf wrote: > I coult get rid of those by using the setarch tool and the > trivial patch below: > $ setarch i386 ../cln/configure -C 'CFLAGS=-m32 -g -O2' \ > 'CXXFLAGS=-m32 -g -O2' LDFLAGS=-m32 > $ setarch i386 make make failed with similar linker errors, the differences are: 1. additional undefined references to `_GLOBAL__I_cl_module__cl_ieee__firstglobalfun 2. the undefined references to mulu64_high and divu64_rest disappeared. btw, make without setarch i386 said exactly the same. installed cln on a pentium: no errors, make check passed, make install works. I couldn't use it to build GiNaC because I don't know how to tell GiNaC to find cln in my customized install dir, any hints? So I wrote a small sample program using cln: #include <iostream> #include <cln/real_io.h> #include <cln/random.h> #include <cln/real.h> using namespace std; using namespace cln; int main() { cl_R r=random_R(1.); cl_R s=exp(r); cout <<s <<endl; return 0; } and that worked on the x86. Then I copied libs and include to the xeon and compiled the program. With and without setarch i386, it complaint: .../cln/object.h:29: warning: "cl_word_alignment" redefined .../cln/number.h:187: error: `cl_FN_tag' undeclared .../cln/float_class.h:43: error: `cl_SF_tag' undeclared is this of any help? cheers werner

2 1

CLN 1.1.9 released
by Richard B. Kreckel 04 Nov '04

04 Nov '04

Good evening, It is my pleasure to announce the release of CLN 1.1.9. This is a maintenance release without any funky new features or any incompatibilities whatsoever. There is no reason for an immediate upgrade if you have been lucky with CLN 1.1.8. To quote NEWS file: Algorithmic changes ------------------- * Input of numbers in bases 2, 4, 8, 16 and 32 is now done in linear bit complexity as opposed to O(N^2). Useful for all kinds of persistency. Implementation changes ---------------------- * Fixed several bugs in the integer input and output routines that could be blamed for random crashes in the following cases: output in base 32 for quite large numbers, input in base 2 for fixnums and input in base 3 for fixnums on a 64 bit target. * Fixed crash when radix specifiers were used in input streams. * Speed up on x86_64 and ia64 by adding some inline assembly. Other changes ------------- * Fixes for compilation on MacOS X and little endian Mips. You may download the source tarball via anonymous FTP from <ftp://ftpthep.physik.uni-mainz.de/pub/gnu/cln-1.1.9.tar.bz2>. Happy hacking -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

make failed on .libs/exam
by Werner Horbelt 29 Oct '04

29 Oct '04

dear wizards, I failed to build cln on a 64 bit dual Pentium Xeon system with SuSE linux: uname -a Linux gulvain 2.6.5-7.108-smp #1 SMP Wed Aug 25 13:34:40 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux g++ --version g++ (GCC) 3.3.3 (SuSE Linux) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ./configure --prefix=/scratch/werner/ # I don't have root access to this machine unfortunately # output seemed all right make # seemed all right until: ... rm -fr .libs/libcln.la .libs/libcln.* .libs/libcln.* *** Warning: linker path does not have real file for library -lgmp. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libgmp but no candidates were found. (...for file magic test) *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. gcc -shared ... -o .libs/libcln.so.3.0.2 ... cd tests; make all ... g++ -g -O2 exam.o exam_I.o exam_RA.o exam_SF.o exam_FF.o exam_DF.o exam_LF.o exam_I_gcd.o exam_I_sqrtp.o -o .libs/exam ../src/.libs/libcln.so -lgmp -lm -Wl,--rpath -Wl,/scratch/werner//lib ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_SV_ringelt__firstglobalfun' ../src/.libs/libcln.so: undefined reference to `mulu64_high' ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_GV_number__firstglobalfun' ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_GV_I__firstglobalfun' ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_SV_number__firstglobalfun' ../src/.libs/libcln.so: undefined reference to `divu_64_rest' ../src/.libs/libcln.so: undefined reference to `_GLOBAL__I_cl_module__cl_symbol__firstglobalfun' collect2: ld returned 1 exit status is there hope? what's gmp? is .libs/exam important? thanx werner

7 14