- CLN-list - ginac.de

Re: [CLN-list] Operations with different precisions
by Bruno Haible 12 Oct '09

12 Oct '09

Sebastian Macke wrote: [Please keep cln-list in CC. If you write to me privately, the probability that you get a response is less than 0.3.] > I used your library with a template class. > template <class T> > Here I define one and zero as > T(1.) > T(0.) Please read again the essential, central chapter "Ordinary number types" of the CLN documentation. From it, it follows that - Numbers such as 1.0 or 0.0 are floating-points and thus are approximate. - If you want a "one" and "zero" in a ring, you should take exact numbers, (cl_I)1 or (cl_I)0. - You don't need templates, because the cl_F, cl_R, cl_N types already comprise 'float' and 'double' (and longer) precisions. > This works without problem with float, double and long double > But with your implementation I can lose precision. In the previous mail I explained to you that when you combine two floating- point numbers with different precision, the result will have an accuracy that approximately equals the minimum of the two precisions. This is a mathematical property of the definition of accuracy. (You can verify it with interval arithmetic or with statistics, if you like.) You then have the choice: - Return a result with a precision approximately equal to its accuracy. This is what CLN does. Or - Return a result whose precision is the *maximum* of the two precisions. If you do this, you are betraying the user of your program. Bruno

1 0

Operations with different precisions
by Sebastian Macke 12 Oct '09

12 Oct '09

Hi, following code snippet cln::cl_F x = cl_float(0.5, cln::float_format(50)); x = cos(x); cout << "\n" << x << "\n"; x = x + cln::cl_F(1.); cout << x << "\n"; gives the output 0.8775825618903727161162815826038296519916451971097440529976L0 1.8775825618903728d0 Is there a feature that the float with the highest precision is used as the result precision? Thanks Sebastian

3 2

CLN and Microsoft Compiler
by Christian Stussak 30 Sep '09

30 Sep '09

Hi, I would like to use CLN (and later Ginac) together with the Compiler Tools provided by Microsoft. I am working on a project, which is fixed to the Microsoft compiler for the Windows build. So I tried to build CLN with the help of cccl (see http://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-using-sources…) which works great for most of the source. I had some problems with the small files, that are written in assembler, but I managed to compile them seperatly to create the .obj files needed for the shared library. After having compiled all files with the Microsoft compiler under cygwin, the link process fails with lots of undefined refs to core functions of cln. Most of them are located in the header files cl_low.h and cl_DS.h. But I cannot figure out, why the DLL build fails. Is anyone interested in the subject? I think, it would be a great thing to finally get CLN to work under Visual Studio. And I almost got it ... Please help me to get through it. Regards Christian -- Dipl.-Inform. Christian Stussak Martin-Luther-Universitaet Halle-Wittenberg Naturwissenschaftliche Fakultaet III Institut fuer Informatik Von-Seckendorf-Platz 1 06120 Halle (Saale) Phone +49 0345 55 24744 Email stussak(a)informatik.uni-halle.de Web http://www.informatik.uni-halle.de/~stussak

1 0

CLN 1.3.0 has been released
by Richard B. Kreckel 24 Sep '09

24 Sep '09

Hi! This release fixes a crash in double_approx(cl_RA) on 64-bit platforms and adds basic support for Renesas SH (sh4). It may be obtained from the usual place: <http://www.ginac.de/CLN/>. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 1

Making new releases: libtool
by Richard B. Kreckel 22 Sep '09

22 Sep '09

Hi Ralf! I just figured I would like to make a new release of CLN. I then realized that setting version numbers has always been confusing me. Until now, I've never cared as much about this as I should, but this should some day get clarified. The configure.ac file in CLN says: dnl * increment CL_REVISION, dnl * if any functions/classes have been added, removed or changed, dnl increment CL_CURRENT and set CL_REVISION to 0, dnl * if any functions/classes have been added, increment CL_AGE, dnl * if backwards compatibility has been broken, set CL_AGE to 0. dnl $(CL_CURRENT):$(CL_REVISION):$(CL_AGE) results in dnl libcln.so.$(CL_CURRENT)-$(CL_AGE) Okay, let's see. I've fixed a function that used to segfault and I've added support for a platform that was not supported before. I increment CL_REVISION. Have I added, removed ro changed a function or class? I'm not sure. Interface-wise not. But I've changed functionality (it doesn't crash any more). So I increment CL_CURRENT to 7 and set CL_REVISION to 0. I haven't added functions/classes, so I don't touch CL_AGE. And I haven't broken backwards compatibility, so I leave CL_AGE at 0. This results in libcln.so.7.0.0, which is clearly bogus, since the new version is a drop-in replacement for the old one! So, back to the second item: Maybe I shoudn't have incremented CL_CURRENT. Then, CL_REVISION is still 0. I haven't added functions/classes, so CL_AGE remains at 0, and I haven't broken backwards compatibility. Oops, then all version numbers remain the same. This is bogus, too! The confugure.ac file in GiNaC is slightly less ambiguous: dnl When making releases, do dnl 1. Increment ginac_lt_revision dnl 2. If any interfaces have been added, removed, or changed since the dnl last release, increment ginac_lt_current and set dnl ginac_lt_revision to 0. dnl 3. If any interfaces have been removed since the last release, set dnl ginac_lt_age to 0. Let's see what happens when I apply this to the new CLN release. This is more clear, since it refers to "interfaces" as opposed to "functions/classes". So I end up with REVISION=1, CURRENT=6 (as before), and AGE=0. This looks better and results in libcln.so.6.0.1. But is this correct? AGE is never incremented! Can you suggest better texts for configure.ac, so making new releases becomes painless? I shamefully have to admit that reading the libtool documentation did not really enlighten me. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

2 2

Bug in double_approx() for cl_RA on x86_64
by Igor Khavkine 11 Sep '09

11 Sep '09

Hello. I've run into a bug in the following routine: src/float/dfloat/conv/cl_RA_to_double.cc : double_approx() A test case is attached. It is supposed to print the rational number 2/3 as a string, a float, and a double. On any 32-bit machine I've tried, it works perfectly. However, on 64-bit machines, I find that the conversion to double generates a segmentation fault. My version is cln-1.2.2. However, looking at the revision history of the relevant file, I don't see what would have fixed this in 1.3.0, so presumably the bug could still be there. It'd be great if someone could look into this. Thanks. Igor

2 2

compililing with cln doesn't work
by Marcel Schulz 01 Sep '09

01 Sep '09

Hi, I have installed the CLN library version 1.3.0 and wanted to use it. however I am not able to compile even the simple fibonacci.cpp example. I have installed the library with ./configure --prefix=/home/schulz_m and i tried to use your documentation to set all the compiler flags appropriately. the original files after unpacking are under /home/schulz_m/cln-1.3.0 and the fibon.cpp is in my home directory. after typing make test I get the following error (makefile and cpp, g++ version below): make test g++ -02 -I/home/schulz_m/include/ -Icln-1.3.0/include/ fibon.cpp -o test g++: unrecognized option '-02' /tmp/ccJKw2VF.o: In function `__static_initialization_and_destruction_0(int, int)': fibon.cpp:(.text+0x159): undefined reference to `cln::cl_random_def_init_helper::cl_random_def_init_helper()' fibon.cpp:(.text+0x18d): undefined reference to `cln::cl_FF_globals_init_helper::cl_FF_globals_init_helper()' fibon.cpp:(.text+0x1b5): undefined reference to `cln::cl_DF_globals_init_helper::cl_DF_globals_init_helper()' fibon.cpp:(.text+0x1dd): undefined reference to `cln::cl_LF_globals_init_helper::cl_LF_globals_init_helper()' /tmp/ccJKw2VF.o: In function `__tcf_4': fibon.cpp:(.text+0x22a): undefined reference to `cln::cl_LF_globals_init_helper::~cl_LF_globals_init_helper()' /tmp/ccJKw2VF.o: In function `__tcf_3': fibon.cpp:(.text+0x23e): undefined reference to `cln::cl_DF_globals_init_helper::~cl_DF_globals_init_helper()' /tmp/ccJKw2VF.o: In function `__tcf_2': fibon.cpp:(.text+0x252): undefined reference to `cln::cl_FF_globals_init_helper::~cl_FF_globals_init_helper()' /tmp/ccJKw2VF.o: In function `__tcf_1': fibon.cpp:(.text+0x266): undefined reference to `cln::cl_random_def_init_helper::~cl_random_def_init_helper()' /tmp/ccJKw2VF.o: In function `fibonacci(int)': fibon.cpp:(.text+0x2c0): undefined reference to `cln::float_format(unsigned long long)' fibon.cpp:(.text+0x2fc): undefined reference to `cln::sqrt(cln::cl_F const&)' fibon.cpp:(.text+0x3c7): undefined reference to `cln::expt(cln::cl_R const&, long)' fibon.cpp:(.text+0x3e3): undefined reference to `cln::operator/(cln::cl_R const&, cln::cl_R const&)' fibon.cpp:(.text+0x3f8): undefined reference to `cln::round1(cln::cl_R const&)' /tmp/ccJKw2VF.o: In function `cln::cl_I_classes_dummy::cl_I_classes_dummy()': fibon.cpp:(.gnu.linkonce.t._ZN3cln18cl_I_classes_dummyC1Ev+0x9): undefined reference to `cln::cl_class_fixnum' /tmp/ccJKw2VF.o: In function `cln::cl_gc_dec_pointer_refcount(cln::cl_heap*)': fibon.cpp:(.gnu.linkonce.t._ZN3cln26cl_gc_dec_pointer_refcountEPNS_7cl_heapE+0x28): undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /tmp/ccJKw2VF.o: In function `cln::operator/(cln::cl_R const&, int)': fibon.cpp:(.gnu.linkonce.t._ZN3clndvERKNS_4cl_REi+0x2e): undefined reference to `cln::operator/(cln::cl_R const&, cln::cl_R const&)' /tmp/ccJKw2VF.o: In function `cln::cl_float(int, cln::float_format_t)': fibon.cpp:(.gnu.linkonce.t._ZN3cln8cl_floatEiNS_14float_format_tE+0x41): undefined reference to `cln::cl_float(cln::cl_I const&, cln::float_format_t)' /tmp/ccJKw2VF.o: In function `cln::operator+(int, cln::cl_R const&)': fibon.cpp:(.gnu.linkonce.t._ZN3clnplEiRKNS_4cl_RE+0x2e): undefined reference to `cln::operator+(cln::cl_R const&, cln::cl_R const&)' collect2: ld returned 1 exit status make: *** [test] Error 1 ----makefile CLN_DIR=/home/schulz_m/ CLN_TARGETDIR=cln-1.3.0/ CC=g++ CFLAGS= -I$(CLN_DIR)include/ -I$(CLN_TARGETDIR)include/ CXXFLAGS= -02 test: $(CC) $(CXXFLAGS) $(CFLAGS) fibon.cpp -o test all: test ----fibon.cpp: #include <iostream> //#include <cln/cln.h> #include "cln/integer.h" #include "cln/real.h" using namespace cln; // Returns F_n, computed as the nearest integer to // ((1+sqrt(5))/2)^n/sqrt(5). Assume n>=0. cl_I fibonacci (int n) { // Need a precision of ((1+sqrt(5))/2)^-n. float_format_t prec = float_format((int)(0.208987641*n+5)); cl_R sqrt5 = sqrt(cl_float(5,prec)); cl_R phi = (1+sqrt5)/2; return round1( expt(phi,n)/sqrt5 ); } int main(){ cl_I tt=fibonacci(4); std::cout<< "fibon:"; return 1; } ----this is my g++ version Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.0/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-nls --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0 Thanks for any advice! Best wishes, Marcel

2 1

cln/ginac port to windows
by Michael Miller 27 Aug '09

27 Aug '09

Having a need to do high-precision calculations in both Linux and Windows, I've ported cln and ginac to Windows, and I thought it'd be appropriate to share the results. (I've been using cln for a couple of years now, and I'm deeply impressed with it. I haven't yet gotten far into ginac, but it's something that I'd also like to support.) I have: 1) A 47MB zip file, containing - the gcc compiler, ported under mingw, along with the gmp and cln libraries - the notepad++ editor - a batch file that allows notepad++ to be used as a simple ide 2) A 69MB zip file containing all of the above, plus the ginac libraries. 3) A rather detailed summary of the process used to assemble the above. When unzipped, the resulting code can be used on any Windows machine without the need for installation or presence of cygwin (it will even run directly from a CD). This will make cln and ginac accessible to a wider audience, which is why I thought it'd be a good idea to share it. It makes sense to have these files hosted on the official ginac/cln site. Any suggestions about who I should contact to make arrangements? Thanks! Mike Miller

3 6

CLN 1.3.0 has been released
by Richard B. Kreckel 01 Jul '09

01 Jul '09

Hi! It may be obtained from the usual place: <http://www.ginac.de/CLN/>. Luck! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

CLN 1.3.0 coming soon
by Richard B. Kreckel 24 Jun '09

24 Jun '09

Hi, I've successfully compiled the current CLN git snapshot on all Debian architectures and plan to release it soon. Please give it a try and report any problem you find to this list. You may get the tarball from: <ftp://ftp.debian.org/debian/pool/main/c/cln/cln_1.3.0~beta2.orig.tar.gz>. Bye -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

2 3