- CLN-list - ginac.de

floating point underflow - a possible explanation
by Michael Schuster 29 Oct '07

29 Oct '07

Hi again, when thinking of my problem, I found the following (it's a bit talking to myself, but perhaps you can find it useful). + The problem with the underflow happens (at least in my case) because the declaration in fnCalc3() Real y2 = Real(string("-6.6061s14"));y Real wrapper class. makes a cl_SF out of y2. The other variable is cl_LF. It seems this causes the underflow. + Actually I thought, this problem can not occur - that's why I use the wrapper class, as I always use the double initialisation- But I found this: valarray<Real> c; c.resize(3); Real dd=c[0]; valarray will call default constructor which is Real():cl_F() and therefore produce a c[0] with type cl_SF. Ok, didnot think of that. My problem. Anyway with the following I get a lot of conversions then dd=Real(1.0/3.0); <<= cl_LF dd=Real(1.0/3.0)+c[0]; <<= back cl_SF again dd=c[0]+Real(1.0/3.0); <<= still cl_SF So once I have cl_SF in my system, it can be anywhere. So now I changed default constructor to Real():cl_F(cl_float(cl_I(0),float_format(_PRECISION_CLN_NEWMAT))) {}; and everthing seems ok now. To be absolutely sure I can change also Real(const cl_F &f):cl_F(cl_float(f,float_format(_PRECISION_CLN))) {} in my wrapper. (The string initialization is intentional.) Michael Watch this!! 1.49557e-52 Am Montag 29 Oktober 2007 schrieb Michael Schuster: > Hi Richy & Cln-List, > > Am Samstag 27 Oktober 2007 schrieb Richard B. Kreckel: > > In order for anyone to be able to help you it is essential that you > > write a reduced test case where the problem appears and can be > > investigated. > > Attachted I made a little demo programm which shows the problem. My output > is : > fnCalc1:1.49557e-52 > fnCalc2:1.49557e-52 > fnCalc2 + 0 :1.49557e-52 > fnCalc3:0 > Watch this!! 0 > Watch this!! 1.49557e-52 > > The line >>Watch this!! 0<< should be >>Watch this!! 1.49557e-52<< at > least in my mathematical opion. > > Ok, I donot know if my construct with the class Real is a possibile good > design. I wanted to have an easy possibility to switch from built-in-double > type to a class type with higher precision. > > Another problem is why I come (in my original programm) to a Real > value-type of cl_SF while I only use the Real base class with cl_float() > function as in the demo. But this is for next mailings here. > > My system: > $gcc --version > gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux) > Copyright (C) 2005 Free Software Foundation, Inc. > Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es > gibt KEINE Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE > ZWECKE. > > $rpm -q cln > cln-1.1.9-5 > > Thanks for any hint. > > Michael

2 1

floating point underflow
by Michael Schuster 29 Oct '07

29 Oct '07

Hi, I'm facing a problem using cöln (1.1.9 and 1.1.13) with my 32 Bit Linux-Athlon System here: I have expression like b+(a*a*a-a)*h/2 Some "a" are rather small, so I retrieve an underflow. I did inhibit this then, but the older version seems to stop calculation in a correct manner (results of other expressions in my programms can not be correct) and the newer says: "Internal error: statement in File ./float/elem/cl_F_mul.cc line 25 has been reached." Thanks for any hint Michael

2 2

Re: [CLN-list] CLN vs Cygwin [Was: cln compile error]
by cbouchrd＠uiuc.edu 19 Oct '07

19 Oct '07

Made suggested changes. Compiler appeared to make it past this point and crash in new spot. On-screen indications point to problem with generation of CLN documentation. I've attached compile.log.gz. Thanks for help to date. Regards, Chris ---- Original message ---- >Date: Thu, 18 Oct 2007 15:21:59 +0400 >From: Alexei Sheplyakov <varg(a)theor.jinr.ru> >Subject: Re: [CLN-list] CLN vs Cygwin [Was: cln compile error] >To: CLN discussion list <cln-list(a)ginac.de> > >Hello! > >On Tue, Oct 16, 2007 at 08:05:43PM -0500, cbouchrd(a)uiuc.edu wrote: > >> >Do you have the same problem when compiling static library only? i.e. >> >make clean &&./configure --disable-shared && make >> >> Yes. I've now compiled both ways and the on screen indications are identical. > >Could you please try this patch: > >[PATCH] zerop(cl_I& const): be more ISO C++ friendly. > >CLN's MAYBE_INLINE violates ISO C++, which demands (in 7.1.2.4) >"If a function with external linkage is declared inline in one translation >unit, it shall be declared inline in all translation units in which it >appears; no diagnostic is required." >This results in link errors on non-ELF platforms (MinGW, Cygwin, Darwin). >In particular, cl_I_ring.cc contains the following code: >extern bool zerop (const cl_I& x); // from <cln/integer.h> >inline bool zerop (const cl_I& x) // from cl_I.h >{ > return x.word == cl_combine(cl_FN_tag,0); >} > >static cl_number_ring_ops<cl_I> I_ops = { > cl_I_p, > equal, > zerop, // ... > >Since the address of zerop is taken here, the compiler is forced to emit >zerop function out-of-line. This results in duplicate symbols (which is >an error). > >--- > src/integer/ring/cl_I_ring.cc | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > >diff --git a/src/integer/ring/cl_I_ring.cc b/src/integer/ring/cl_I_ring.cc >index 416738a..fd96c12 100644 >--- a/src/integer/ring/cl_I_ring.cc >+++ b/src/integer/ring/cl_I_ring.cc >@@ -13,7 +13,9 @@ CL_PROVIDE(cl_I_ring) > > #include "cln/integer.h" > #include "cln/integer_io.h" >+#define zerop inline_zerop > #include "cl_I.h" >+#undef zerop > > namespace cln { > >@@ -34,10 +36,11 @@ static const _cl_ring_element I_zero (cl_heap_ring* R) > return _cl_ring_element(R, (cl_I)0); > } > >+static bool I_zerop (cl_heap_ring* R, const _cl_ring_element& x) __attribute__((flatten)); > static bool I_zerop (cl_heap_ring* R, const _cl_ring_element& x) > { > unused R; >- return zerop(The(cl_I)(x)); >+ return inline_zerop(The(cl_I)(x)); > } > > static const _cl_ring_element I_plus (cl_heap_ring* R, const _cl_ring_element& x, const _cl_ring_element& y) >-- >1.5.3.2 > >Best regards, > Alexei > >-- >All science is either physics or stamp collecting. > >________________ >signature.asc (1k bytes) >________________ >_______________________________________________ >CLN-list mailing list >CLN-list(a)ginac.de >https://www.cebix.net/mailman/listinfo/cln-list

1 0

Re: [CLN-list] CLN vs Cygwin [Was: cln compile error]
by cbouchrd＠uiuc.edu 18 Oct '07

18 Oct '07

Hi, Sorry for the delay... ---- Original message ---- >Date: Sat, 13 Oct 2007 19:17:13 +0400 >From: Alexei Sheplyakov <varg(a)theor.jinr.ru> >Subject: [CLN-list] CLN vs Cygwin [Was: cln compile error] >To: CLN discussion list <cln-list(a)ginac.de> > >Hello! > >On Fri, Oct 12, 2007 at 12:10:56PM -0500, cbouchrd(a)uiuc.edu wrote: > >> I have another compile issue, this time due to an apparent problem >> with undefined variables. > >Do you have the same problem when compiling static library only? i.e. >make clean &&./configure --disable-shared && make Yes. I've now compiled both ways and the on screen indications are identical. > >> I've attached two screen shots (with signifcant snipping between them) >> that may be useful. > >Unfortunately the text is almost unreadable (should I upgrade my >glasses?). Could you please send the compilation log instead? E.g. > >make 2>&1 | gzip -9 > compile.log.gz > >and post the compile.log.gz file. > The file is attached. >Best regards, > Alexei > >-- >All science is either physics or stamp collecting. > >________________ >signature.asc (1k bytes) >________________ >_______________________________________________ >CLN-list mailing list >CLN-list(a)ginac.de >https://www.cebix.net/mailman/listinfo/cln-list Thanks, Chris

2 1

Re: [CLN-list] cln compile error
by cbouchrd＠uiuc.edu 15 Oct '07

15 Oct '07

In "/cln/src/float/transcendental/cl_LF_zeta_int.cc" there are two occurrences of "_N" and two of "_s". I renamed both variables as you recommended and the error disappeared. I haven't encountered this problem again but I'm not done yet. I have another compile issue, this time due to an apparent problem with undefined variables. I've attached two screen shots (with signifcant snipping between them) that may be useful. I've also attached the config.log. Thanks again for any help! Regards, Chris Bouchard ---- Original message ---- >Date: Fri, 12 Oct 2007 16:44:57 +0200 >From: "Richard B. Kreckel" <kreckel(a)ginac.de> >Subject: Re: [CLN-list] cln compile error >To: CLN discussion list <cln-list(a)ginac.de> > >cbouchrd(a)uiuc.edu wrote: >> I'm getting a compile error similar to that reported in the Nov '07 thread of same subject name. I'm too ignorant, however, to apply the fix provided in that thread to my problem (if, in fact, it is applicable). >> >> I've included the config.log and a screen shot of the compile error. >> >> At first blush I thought the problem was in line 115 of "cl_LF_zeta_int.cc". After scanning the config.log and reading the old thread, though, it seems possible that the problem is within "confdefs.h" >> >> My operating system is Windows XP with CYGWIN. >> >> Thanks for any help. I look forward to using xloops/GiNaC/CLN in the near future! > >You are using a prerelease of CLN 1.2.0 from CVS and your compiler is >defining either _s or _N as some number. Can you, please, rename that >variable and try again? > >I wish to fix such things before the release of CLN 1.2.0, but I suspect >there are a number of other places where you'll have to apply the same >fix. Please, find them and send them to me (or this list). > >Thanks in advance > -richy. >-- >Richard B. Kreckel ><http://www.ginac.de/~kreckel/> >_______________________________________________ >CLN-list mailing list >CLN-list(a)ginac.de >https://www.cebix.net/mailman/listinfo/cln-list

4 5

cln compile error
by cbouchrd＠uiuc.edu 12 Oct '07

12 Oct '07

I'm getting a compile error similar to that reported in the Nov '07 thread of same subject name. I'm too ignorant, however, to apply the fix provided in that thread to my problem (if, in fact, it is applicable). I've included the config.log and a screen shot of the compile error. At first blush I thought the problem was in line 115 of "cl_LF_zeta_int.cc". After scanning the config.log and reading the old thread, though, it seems possible that the problem is within "confdefs.h" My operating system is Windows XP with CYGWIN. Thanks for any help. I look forward to using xloops/GiNaC/CLN in the near future! Regards, Chris Bouchard

2 1

How to cite cln
by Wilson Castro 28 Jul '07

28 Jul '07

Hello cln-developers and cln-listmoderator, I want to know how it is the correct form to cite cln. 1. first in a paper? 2. in a GNU-software for Linux that uses the library? best regards -- Ms. C. Wilson Castro Rojas Foundations of Informatics Group, Department of Informatics, University of Kaiserslautern, Germany, PO Box: 3049, Building: 34/423, Phone: ++49 631 205 2155, Fax: ++49 631 205 2156,

5 33

[bug] CLN - pi example program does not report correct accuracy
by xt knight 28 Jul '07

28 Jul '07

Sorry, I posted this to ginac-list before I realized there was also a cln-list. I hope it gets to the right people involved. This is a simple bug and it's reproducible on every machine. Using the pi example in libcln (./examples), type this: pi 5 3.1415927 is not 5 digits. pi 1 3.1416 is not 1 digit. https://bugs.launchpad.net/debian/+source/cln/+bug/128851 This bug reporter also mentions that it rounds the last number and that's not documented anywhere. Thank you for your time, xtknight

1 0

bug in CLN RPM packaging system
by Markus Grabner 20 Jun '07

20 Jun '07

Hi! There is a small bug in the spec-file included in the CLN package "http://www.ginac.de/CLN/cln-1.1.13.tar.bz2". The package is compressed by "bzip2" and has extension ".bz2", but the spec-file refers to a "gzip"-compressed file with extension ".gz", so the command rpmbuild -ta cln-1.1.13.tar.bz2 fails. A workaround could be to uncompress the file and re-compress it with gzip, but this is somewhat inconvenient, and the issue is easily fixed by replacing ".gz" by ".bz2" in the spec-file. Kind regards, Markus -- Markus Grabner - Computer Graphics and Vision Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria Phone: +43/316/873-5041, Fax: +43/316/873-5050 WWW: http://www.icg.tugraz.at/Members/grabner

2 1

Multiple definition errors when natively compiling CLN 1.1.13 with GCC 3.4 for ARM target
by Simon Pickering 28 Feb '07

28 Feb '07

Hello, I'm attempting to compile CLN 1.1.13 using GCC 3.4 (inside scratchbox using qemu which allows GCC to be a native ARM compiler). I am compiling for the Nokia N800. I'm compiling with the following configure command: ./configure --with-gmp --prefix=/usr and with the following env vars: CPPFLAGS="-DNO_ASM" CXXFLAGS="-O2 -fno-exceptions -finline-limit=1000 -mfpu=vfp -mfloat-abi=softfp" I get the following error (trimmed as the preceeding command is very long): /bin/sh ../libtool --mode=link g++ -o libcln.la -rpath /usr/lib -version-info 4:2:0 -lgmp -objectlist libcln.objectlist g++ -shared -nostdlib /scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/lib/crti.o <snip> .libs/cl_asm_.o /usr/lib/libgmp.so -L/scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4 -L/usr/lib/gcc/arm-none-linux-gnueabi/3.4.4 -L/scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/lib -lstdc++ -lm -lc -lgcc_s /scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4/crtendS.o /scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/lib/crtn.o -Wl,-soname -Wl,libcln.so.4 -o .libs/libcln.so.4.0.2 .libs/cl_I_ring.o: In function `cln::zerop(cln::cl_I const&)':cl_I_ring.cc:(.text._ZN3cln5zeropERKNS_4cl_IE[cln::zerop(cln::cl_I const&)]+0x0): multiple definition of `cln::zerop(cln::cl_I const&)' .libs/cl_I_zerop.o:cl_I_zerop.cc:(.text+0x0): first defined here .libs/cl_RA_ring.o: In function `cln::zerop(cln::cl_RA const&)':cl_RA_ring.cc:(.text._ZN3cln5zeropERKNS_5cl_RAE[cln::zerop(cln::cl_RA const&)]+0x0): multiple definition of `cln::zerop(cln::cl_RA const&)' .libs/cl_RA_zerop.o:cl_RA_zerop.cc:(.text+0x0): first defined here .libs/cl_R_signum.o: In function `cln::signum(cln::cl_I const&)':cl_R_signum.cc:(.text._ZN3cln6signumERKNS_4cl_IE[cln::signum(cln::cl_I const&)]+0x0): multiple definition of `cln::signum(cln::cl_I const&)' .libs/cl_I_signum.o:cl_I_signum.cc:(.text+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [libcln.la] Error 1 make[2]: Leaving directory `/home/simon/build/qcalculate/cln-1.1.13.orig/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/simon/build/qcalculate/cln-1.1.13.orig' make: *** [build] Error 2 I did a search of the mailing list archives and could only find this mentioned for MinGW. There was no solution as far as I could tell, but some talk of --param *inline* options that might make a difference. The installation instructions say the following: "If you use g++ on OSF/1 or Tru64 using gcc-2.95.x, you should specify `--disable-shared' because of linker problems with duplicate symbols in shared libraries.", which sounds like my problem, though obviously on a different platform & compiler version. I have tried altering -finline-limit (removing it, and changing the value to 10000), but to no avail, I still have the problem. I am trying to compile Qalculate, and even if I compile CLN to be a static library, I get linking errors due to the multiple functions when compiling libqalculate. Is there any way around this problem? Any other -finline*/--param options I could try, etc., or any other ideas? Many thanks, Simon P.S. I'm not subscribed to the list, but can do so if needed.

3 3