- CLN-list - ginac.de

Convert CLN's rationals to GMP
by Florian Pigorsch 27 Nov '07

27 Nov '07

Hi, I need to convert rationals of the CLN library (cln::cl_RA) to the rational format of GMP (mpq_t). Since CLN internally uses GMP this should be simple, but I didn't find a way to do the conversion. Does anyone know how to do it? Thanks in advance, Florian

1 0

Re: [cln] sparc64 and OpenBSD
by Richard B. Kreckel 19 Nov '07

19 Nov '07

Hi Paul, (I'm CCing the mailing list.) Paul Irofti wrote: > I'm currently porting cln on OpenBSD. I'm having some problems with the > sparc64 arch. I fixed some bugs and have others in my to do list. Thanks you very much. Your patches are against CLN 1.1.13. Could you, please, check out CVS HEAD instead (a.k.a. CLN 1.2-pre)? At least the "\n\t" patch is already in there. $ cvs -d :pserver:anoncvs@cvs.ginac.de:/home/cvs/cln login [enter the password `anoncvs'] $ cvs -d :pserver:anoncvs@cvs.ginac.de:/home/cvs/cln -z 9 co cln A while ago Sven Verdoolaege gave sparc64 a try. But he seems to have given up rather quickly: <http://www.ginac.de/pipermail/cln-list/2006-December/000265.html> > Currently I'm stuck on one in polynomial/elem. It has to do with a > multiplication. > > In src/polynomial/elem/cl_UP_GF2.h, why do you define the gf2_mul_table > only for arches that are not sparc? Calls to this table are made further > for arches that have intDsize=64 (that includes sparc64) and thus error > out. > > I'll further let the error messages and the patches talk for them selfs. > > Please get back to me so we can fix these and make cln available for > OpenBSD. FreeBSD already marked sparc64 as broken arch and NetBSD, > apparently, didn't even test it on this platform. I'm no Sparc expert. To me, some of the patches don't talk for themselves. Can you, please, add short Changelog entries? > ------------------------------------------------------------------------ > > /usr/local/bin/libtool --mode=compile c++ -O2 -pipe -Wformat -Wbounded > -I/usr/local/include -I../include -I../include -I./polynomial -I./base > -I./base/hash -I./base/digitseq -I./base/digit -Ibase -c > ./polynomial/elem/cl_UP.cc > c++ -O2 -pipe -Wformat -Wbounded -I/usr/local/include -I../include > -I../include -I./polynomial -I./base -I./base/hash -I./base/digitseq > -I./base/digit -Ibase -c ./polynomial/elem/cl_UP.cc -fPIC -DPIC -o > .libs/cl_UP.o > In file included from ../include/cln/univpoly.h:6, > from polynomial/elem/cl_UP.cc:11: > ../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 > In file included from polynomial/elem/cl_UP.cc:36: > polynomial/elem/cl_UP_GF2.h: In function `uint64 cln::gf2_mul32_(unsigned > int, unsigned int)': > polynomial/elem/cl_UP_GF2.h:766: error: `gf2_mul_table' undeclared (first > use this function) > polynomial/elem/cl_UP_GF2.h:766: error: (Each undeclared identifier is > reported only once for each function it appears in.) > > > > ------------------------------------------------------------------------ > > $OpenBSD$ > --- src/base/cl_low.h.orig Mon Nov 12 17:43:08 2007 > +++ src/base/cl_low.h Mon Nov 12 17:48:07 2007 > @@ -238,7 +238,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar > #define mulu32(x,y,hi_zuweisung,lo_zuweisung) \ > ({ var register uint64 _hi; \ > var register uint64 _lo; \ > - __asm__("umul %2,%3,%1\n\trd %y,%0" \ > + __asm__("umul %2,%3,%1\n\trd %%y,%0" \ > : "=r" (_hi), "=r" (_lo) \ > : "r" ((uint32)(x)), "r" ((uint32)(y)) \ > ); \ > @@ -429,7 +429,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar > __asm__ __volatile__ ( \ > "wr %%g0,%%g0,%%y\n\t" \ > "udiv %2,%3,%0\n\t" \ > - "umul %0,%3,%1" \ > + "umul %0,%3,%1\n\t" \ > "sub %2,%1,%1" \ > : "=&r" (__q), "=&r" (__r) \ > : "r" (__x), "r" (__y)); \ > @@ -518,7 +518,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar > __asm__ __volatile__ ( \ > "wr %%g0,%%g0,%%y\n\t" \ > "udiv %2,%3,%0\n\t" \ > - "umul %0,%3,%1" \ > + "umul %0,%3,%1\n\t" \ > "sub %2,%1,%1" \ > : "=&r" (__q), "=&r" (__r) \ > : "r" (__x), "r" (__y)); \ > @@ -568,7 +568,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar > __asm__ __volatile__ ( \ > "wr %%g0,%%g0,%%y\n\t" \ > "udiv %2,%3,%0\n\t" \ > - "umul %0,%3,%1" \ > + "umul %0,%3,%1\n\t" \ > "sub %2,%1,%1" \ > : "=&r" (__q), "=&r" (__r) \ > : "r" (__x), "r" (__y)); \ > @@ -680,7 +680,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar > __asm__ __volatile__ ( \ > "wr %2,%%g0,%%y\n\t" \ > "udiv %3,%4,%0\n\t" \ > - "umul %0,%4,%1" \ > + "umul %0,%4,%1\n\t" \ > "sub %3,%1,%1" \ > : "=&r" (__q), "=&r" (__r) \ > : "r" (__xhi), "r" (__xlo), "r" (__y)); \ > > > ------------------------------------------------------------------------ > > $OpenBSD$ > --- src/base/digitseq/cl_asm_sparc64_.cc.orig Fri Jan 28 13:37:28 2000 > +++ src/base/digitseq/cl_asm_sparc64_.cc Wed Nov 14 16:42:47 2007 > @@ -42,6 +42,8 @@ > > .seg "text" > > + .register %g2,#scratch > + > .global C(mulu16_),C(mulu32_),C(mulu32_unchecked),C(mulu64_) > .global C(divu_6432_3232_),C(divu_3216_1616_) > .global C(copy_loop_up),C(copy_loop_down),C(fill_loop_up),C(fill_loop_down) Your other patch: > $OpenBSD$ > --- include/cln/object.h.orig Thu Nov 15 11:58:06 2007 > +++ include/cln/object.h Thu Nov 15 11:58:13 2007 > @@ -22,7 +22,7 @@ namespace cln { > #if defined(__m68k__) > #define cl_word_alignment 2 > #endif > -#if defined(__i386__) || defined(__mips__) || defined(__mipsel__) || defined(__sparc__) || defined(__hppa__) || defined(__arm__) || defined(__rs6000__) || defined(__m88k__) || defined(__convex__) || defined(__s390__) > +#if defined(__i386__) || defined(__mips__) || defined(__mipsel__) || (defined(__sparc__) && !defined(__sparc64__))|| defined(__hppa__) || defined(__arm__) || defined(__rs6000__) || defined(__m88k__) || defined(__convex__) || defined(__s390__) > #define cl_word_alignment 4 > #endif > #if defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__sparc64__) || defined(__x86_64__) > > > > $OpenBSD$ > --- src/polynomial/elem/cl_UP_GF2.h.orig Thu Nov 15 11:51:38 2007 > +++ src/polynomial/elem/cl_UP_GF2.h Thu Nov 15 11:56:45 2007 > @@ -746,10 +746,10 @@ uint32 gf2_mul32 (uint32 x, uint32 y, uint32* plo) > > // Multiply two GF2-polynomials of degree < intDsize. > // Stores the low part, returns the high part. > -#if (intDsize==32) > +#if (intDsize==32) || defined(__sparc64__) > #define gf2_mul_uintD gf2_mul32 > #endif > -#if (intDsize==64) > +#if (intDsize==64) && !defined(__sparc64__) > inline uint64 gf2_mul32_ (uint32 x, uint32 y) > { > var uint16 *ptr; // uint16 ptr[0x10]; Aha, so __sparc64__ *is* defined. Good. The earlier patch by Sven Verdoolaege implied that it wasn't. So, you got it to compile in the end? Did you run make check? What did it report? Looking forward to see CLN fixed on sparc64 -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

2 2

Bug in F_2[X] comparisson
by Remco Bloemen 04 Nov '07

04 Nov '07

Dear all, Lately i have been implementing a few algorithms from "Modern Computer Algebra". In the process of implementing Z[x] factorization i noticed the following strange behavior: cl_modint_ring basering = find_modint_ring(2); cl_univpoly_modint_ring ring = find_univpoly_ring(basering); cl_UP_MI x= ring->zero(); (x != ring->zero()) returns false (correct) (x == ring->zero()) returns false (incorrect) If i first compare x == x the behavior changes: (x == x) returns true (correct) (x != ring->zero()) returns true (incorrect) (x == ring->zero()) returns false (incorrect) Attached is a demonstrational program. I'm using cln version 1.1.13 compiled with gcc-4.2.2 on x86 (prescott). Could someone please tell me if this is fixed in cvs or being worked on?

3 5

Using CLN in Objective-C
by Ron Garret 30 Oct '07

30 Oct '07

I would like to use CLN in an Objctive-C project that makes use of the new garbage collector available in Mac OS X Leopard. Based on what I currently know, it seems like it should be a pretty straightforward task to create a thin wrapper in ObjC for CLN objects so that the CLN object is properly disposed of when the wrapper object is garbage collected. But I thought I would check with those of you who are more familiar with the guts of CLN to make sure that there aren't pitfalls that I ought to be aware of before I embark on this, and also to see if anyone besides me is interested in being able to use CLN for Leopard projects. Also, if anyone here has experience in both ObjC and CLN and is interested in some paid contract work related to this project please contact me off-line. rg

2 2

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