- GiNaC-list - ginac.de

Equivalent of evalf for numeric (for fractions)
by Eduardo M Kalinowski 06 Dec '00

06 Dec '00

Hi again, How can I convert a GiNaC::numeric that contains a fraction (or even a integer, for that matter) into a numeric with the real representation of the fraction? Currently I'm adding "0.0" to the numeric to force it into a real number. This works, but is ugly. How about an "evalf" function for GiNaC::numeric? -- I'm always looking for a new idea that will be more productive than its cost. -- David Rockefeller Eduardo M Kalinowski (ekalin(a)iname.com) http://move.to/hpkb http://cami-ufpr.hpg.com.br - To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".

2 2

floor function for GiNaC::numeric
by Eduardo M Kalinowski 11 Nov '00

11 Nov '00

Hi, I've looked through the documentation and header files for GiNaC::numeric and I haven't been able to find the floor (or ceil, for that matter) function for that class. Have I overlooked something, or is that missing? How can I implement one? I know CLN has a floor1 function that is what I want. -- So far we've managed to avoid turning Perl into APL. :-) -- Larry Wall in <199702251904.LAA28261(a)wall.org> Eduardo M Kalinowski (ekalin(a)iname.com) http://move.to/hpkb http://cami-ufpr.hpg.com.br - To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".

2 2

collect problem
by Ben Sapp 20 Oct '00

20 Oct '00

Hi, I have program that crashes when it uses the collect function of the ex class. The strange error I receive is: Not a 32-bit integer: -9223372028264841216 I am able to print both the expression and the symbol I am going to use for the collect call before hand and all seems fine. I archived the symbol and expression just before I knew it would crash and I can look at the function with viewgar. However if I make a program that uses collect on the expression I get the same strange error and the program exits. Is this a bug in GiNaC? Is it a bug in my software? What could be causing this? How can I fix it? I have attached the archive file and the source to the program that reads the archive file. I did not give the source to the software that originally produced it because it is a function that is dynamically linked with another program.(GNU Octave) In case my system configuration is important: [ben@pcben Linux]$ ginac-config --version 0.6.4 [ben@pcben Linux]$ g++ -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gcc version 2.95.2 19991024 (release) [ben@pcben Linux]$ uname -a Linux pcben 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown Thanks for any insight. -- Ben Sapp Los Alamos National Laboratory email: <mailto:bsapp@lanl.gov> Phone: (505)667-3277 Fax: (505)665-7920 URL: http://www.neutrino.lanl.gov/ -- GARCclasssymbolnamexThe symbolmuladdrestnumericnumber1coeffR-1 11529215046068469760 -61overall_coeffpowerbasisR1 9223372036854775808 -62exponentR1 13835058055282163712 -62The expression J J;[kJ{<J;[k;[; [k #include <ginac/ginac.h> #include <iostream> #include <fstream> using namespace GiNaC; int main() { archive a; ifstream in("foobar.gar"); in >> a; symbol x("x"); lst syms(x); ex expr = a.unarchive_ex(syms,"The expression"); cout << "expr = " << expr << endl; cout << expr.collect(x); return(0); }

4 4

Re: Ben Sapp's Problem
by Richard B. Kreckel 20 Oct '00

20 Oct '00

Hi, Sorry, Christian, for putting this into the list so late but I thought Ben and others might wish to know what is going on. And sorry to all the others for the German in it... On Fri, 20 Oct 2000, Christian Bauer wrote: > Ich habe jetzt eine Version gebastelt (noch nicht im CVS), die > nicht-integer-Exponenten bei (l)degree() und coeff() als 0 ansieht, d.h: What I was thinking of, was that ldegree returns the corresponding floor and degree the corresponding ceiling. Is this idea somehow screwed or does it just not matter at all? > > e=5*x^2.0+42*x^3; > 5*x^(2.0)+42*x^3 > > degree(e,x); > 3 > > ldegree(e,x); > 0 > > coeff(e,x,0); > 5*x^(2.0) > > coeff(e,x,2); > 0 > > coeff(e,x,3); > 42 > > collect(e,x); > 5*x^(2.0)+42*x^3 [...] > Etwas inkonsistent finde ich, das in GiNaC > > > is(2.0==2); > 1 > > wo doch 2.0 eigentlich ein inexakter Wert ist. > > Wohingegen > > > x^2.0*x^3; > x^(5.0) > > in Ordnung ist. Hmm, there is no clever way in CLN to do just that, one would have to resort to some (trivial) RTTI-fiddling here. Is this just inconsistent or does this lead to potential problems somewhere? -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/> - To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".

1 0

still problems
by Tilman Utz 19 Sep '00

19 Sep '00

Hi folks, once again I have to ask for your help and advice, although I some moments of success, the great breakthrough is still missing. A lot of my problems in making the library (cln and ginac) resulted from the Windows habit of changing the case of file- and directorynames, e.g. from gmp.h to Gmp.h, so the Makefile didn't find the file. How about you, do you have problems with that, too, and how to prevent it? Well, I changed the filenames by hand and might have missed some. So, the problems I encounter with configure may be a result of that. Here's, what I did and what I got: No problems with installing cygwin 1.1.4 cln-1.0.3 was unzipped and untared to /usr/local, path changed to /usr/local/cln-1.0.3 ./configure --prefix=/usr/local after a while, configure aborts with the message, that it couldn't determine host-type, because config.guess was missing (./config failed for gmp), well, the file is there, but not in ./gmp but in ./autoconf. I move config.guess and later config.sub to ./gmp, then, configure finished without error messages, but in the config.log-File, there are still messages, which are like below: configure:1894: alloca.h: No such file or directory configure: failed program was: #line 1893 "configure" #include "confdefs.h" #include <alloca.h> int main() { char *p = (char *) alloca(2 * sizeof(int)); ; return 0; } similar for filenames like that: fpu_control.h (I can send you the config.log if it might help...) trying the ./configure command again, these errormessages disappear... After executing about half an hour of the Makefile, make stops editing a bunch of errors like: ../src/.libs/libcln.a(cl_F_extendsqrtx.o)(.text+0x611):cl_F_extendsqrtx.cc: unde fined reference to `_GLOBAL_$D$cl_module__cl_ieee__firstglobalfun' ../src/.libs/libcln.a(cl_LF_scale_I.o)(.text+0x532):cl_LF_scale_I.cc: undefined reference to `_GLOBAL_$I$cl_module__cl_ieee__firstglobalfun' ../src/.libs/libcln.a(cl_LF_scale_I.o)(.text+0x539):cl_LF_scale_I.cc: undefined reference to `_GLOBAL_$D$cl_module__cl_ieee__firstglobalfun' ../src/.libs/libcln.a(cl_F_floor22.o)(.text+0x4a6):cl_F_floor22.cc: undefined re ference to `_GLOBAL_$I$cl_module__cl_ieee__firstglobalfun' These occur while the Linker (ld is a linker, isn't it?) is working Within Linux I'm slightly better off. Although I get the config.log errors like above, too, making, checking and installing cln and Ginac works without obvious errors. The GiNaC tests are passed, too, compiling the example program from the GiNaC documentation, works too, but executing the file results in the error that lbginac.0.6.so.3 is not found (although it's in /usr/local/lib). Do you have an idea, what's wrong with my system or the way I try to build the libraries? I have a PentiumIII 600 128MB of RAM, Windows98 and cygwin 1.1.4 installed. Is it possible to transfer the compiled libraries from Linux to cygwin (I mean, gcc is gcc, isn't it?) because I'm more hopeful to bring the libraries to work with LINUX than with Windows... Thanks a lot in advance Tilman Utz - To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".

2 1

RE: GiNaC with gcc for win32]
by Tilman Utz 14 Aug '00

14 Aug '00

> Have just built and installed GiNaC-0.6.4 on NT4 SP5 with cygwin 1.1.4 > > cln-1.0.3 installed with prefix=/usr/local/ > GiNaC source tree /usr/local/src/GiNaC-0.6.4 > > then > CPPFLAGS=-I/usr/local/include > export CPPFLAGS > CXXFLAGS=-I/usr/local/include > export CXXFLAGS > LDFLAGS=-L/usr/local/lib > export LDFLAGS > > mkdir /usr/local/obj/GiNaC-0.6.4 > cd /usr/local/obj/GiNaC-0.6.4 > /usr/local/src/GiNaC-0.6.4/configure > make > make check > > Maximum memory usage during "make check" is about 120 MB. PC has 128 MB > :-> > Sorry, it still won't work. I suceeded in building and installing the cln-library (although I had to switch off gmp, had to type a host in the configure command line and my small example program won't find the libraries without typing the path in the include line). Configuring GiNaC works, too (libreadline wasn't found, but I suppose that's a minor problem) but make aborts after few lines complaining about the following: tilman utz@TILMAN /usr/local/obj/GiNaC-0.6.4 $ make make all-recursive make[1]: Entering directory `/usr/local/obj/GiNaC-0.6.4' Making all in ginac make[2]: Entering directory `/usr/local/obj/GiNaC-0.6.4/ginac' make[2]: *** No rule to make target `add.h', needed by `add.lo'. Stop. make[2]: Leaving directory `/usr/local/obj/GiNaC-0.6.4/ginac' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/obj/GiNaC-0.6.4' make: *** [all-recursive-am] Error 2 I don't have the slightest idea what went wrong this time. Could it be that there's a problem with the directory-structure. Another question: If I ever suceed in building and installing GiNac, too, will I be able to use the library with, let's say Visual Studio (ok, Richard B Kreckel wrote about that in his last Mail, but I didn't understand all, especially, did he refer to building the library or to compiling executables using the library). Thanks and regards Tilman - To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".

2 1

On GiNaC's Portability
by Richard B. Kreckel 12 Aug '00

12 Aug '00

Hi folx, Since we issued warnings all over the place that GiNaC runs with GCC's C++ compiler only, I thought it would be interesting to verify this statement. (Hi Alex! How about MS-VC++ again?) So I took the current Portland Group compiler (version 3.1-3) for Linux/ia32 and gave it a try. Since in C++ mangled names differ across compilers (as mandated by the standard) one first has to compile CLN on that. Otherwise one can't link anything together. Quite contrary to CLN's documentation, it turned out to be rather portable. The only issue (apart from some minor errors I'm going to correct for CLN-1.1) is the scheme of PROVIDE/REQUIRE macros it implements to deal with the 'static initialization order fiasco'. But since this doesn't bite you at all as long as you are building a static library only, 'configure --disable-shared' was enough! In GiNaC, the compiler found a couple of stupidities 'g++ -Wall -ansi -pedantic' never complained about. (Alex, why was 'const basic & basic::operator=(const basic &)' declared virtual? That seems to be wrong because if you override it 'const derived & derived::operator=(const derived &)' does not match.) Anyways, I'll check in the necessary changes later. To my surprise the beast really worked, apart from segfaults each time the program exits and some 'class basic_string' silliness in the compiler. The interesting question is whether this would be a great performance boost, having such an expensive 'professional' compiler. So I ran 'make check' to see the results of the suite of benchmarks. The runtimes are indeed surprising, although not quite as I had expected. Optimization was -O2 for both compilers and according to the documentation this seems to be comparable. -O2 is the highest level of the Portland Group compiler. After that, one can increase automatic inlining and other aggressive optimizations but that seems to eat enormous amounts of memory (>500MB) and tends to crash the compiler. In any case, the compilation process is 10-20 times slower than with GCC. Can you believe they ship encrypted standard library header files but when you crash the compiler and it leaves a dump it is not difficult to put the damnded pieces together? (Only to see that they miss certain things and are not too conforming to the standard.) Obscurity at its best. Duh. Okay, here are the runtimes in seconds. Machine was an Athlon/800 with "enough" memory. Please read it carefully, then light an incense and spend a minute praying to the FSF. pgCC GCC ratio 3.1-3 2.95.2 pgCC/GCC commutative expansion and substitution (25 vars) 0.08 0.01 8.00 (50 vars) 0.32 0.08 4.00 (100 vars) 1.36 0.38 3.58 (200 vars) 5.84 1.74 3.36 Laurent series expansion of Gamma (order 10) 0.26 0.06 4.33 (order 15) 1.49 0.34 4.38 (order 20) 6.73 1.62 4.15 (order 25) 26.17 6.75 3.88 determinant of univariate Vandermonde (dim 4x4) 0.006 0.002 3.00 (dim 6x6) 0.05 0.01 5.00 (dim 8x8) 0.59 0.14 4.21 (dim 10x10) 5.55 1.30 4.27 determinant of polyvariate Toeplitz (dim 5x5) 0.07 0.017 4.12 (dim 6x6) 0.36 0.09 4.00 (dim 7x7) 1.72 0.45 3.82 (dim 8x8) 7.46 2.15 3.47 Lewis-Wester test A (divide factorials) 0.26 0.11 2.36 Lewis-Wester test B (sum of rational numbers) 0.04 0.014 2.86 Lewis-Wester test C (gcd of big integers) 1.10 0.13 8.46 Lewis-Wester test D (sum of rational fcns) 0.0022 0.0004 5.50 Lewis-Wester test E (sum of rational fcns) 0.0023 0.0004 5.75 Lewis-Wester test F (gcd of 2-var polys) 0.082 0.043 1.91 Lewis-Wester test G (gcd of 3-var polys) 2.87 1.68 1.71 Lewis-Wester test H (det of 80x80 Hilbert) 19.46 4.99 3.88 Lewis-Wester test I (invert rank 40 Hilbert) 7.61 2.01 3.79 Lewis-Wester test J (check rank 40 Hilbert) 3.93 0.90 4.37 Lewis-Wester test K (invert rank 70 Hilbert) 44.92 12.39 3.63 Lewis-Wester test L (check rank 70 Hilbert) 22.01 5.44 4.05 Lewis-Wester test M1 (26x26 sparse, det) 0.77 0.24 3.21 Lewis-Wester test O1 (three 15x15 dets, average) 111.95 39.23 2.85 Lewis-Wester test P (det of sparse rank 101) 9.14 3.12 2.93 Lewis-Wester test P' (det of less sparse rank 101) 17.88 5.16 3.47 Lewis-Wester test Q (charpoly(P)) 258.23 80.47 3.21 Lewis-Wester test Q' (charpoly(P')) 521.26 161.33 3.23 Peace, love and free software -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/> - To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".

1 0

RE: GiNaC with gcc for win32
by Billinghurst, David (CRTS) 11 Aug '00

11 Aug '00

Have just built and installed GiNaC-0.6.4 on NT4 SP5 with cygwin 1.1.4 cln-1.0.3 installed with prefix=/usr/local/ GiNaC source tree /usr/local/src/GiNaC-0.6.4 then CPPFLAGS=-I/usr/local/include export CPPFLAGS CXXFLAGS=-I/usr/local/include export CXXFLAGS LDFLAGS=-L/usr/local/lib export LDFLAGS mkdir /usr/local/obj/GiNaC-0.6.4 cd /usr/local/obj/GiNaC-0.6.4 /usr/local/src/GiNaC-0.6.4/configure make make check Maximum memory usage during "make check" is about 120 MB. PC has 128 MB :-> > -----Original Message----- > From: Billinghurst, David (CRTS) > Sent: Thursday, 10 August 2000 9:46 > To: 'ginac-list(a)zino.Physik.Uni-Mainz.DE' > Subject: RE: GiNaC with gcc for win32 > > GiNaC and cln build out of the box with little (or no) problem on NT4 SP5 > using recent cygwin. One of the tests fails occasionally. May be lack of > memory - 128 MB doesn't seem enough these days. My laptop is at home, so > I > don't have the details. Let me know if you have any problems > > +++++++++++++++++++++++++++++++++++++++++ > (Mr) David Billinghurst > Comalco Research Centre > PO Box 316, Thomastown, Vic, Australia, 3074 > Phone: +61 3 9469 0642 > FAX: +61 3 9462 2700 > Email: David.Billinghurst(a)riotinto.com > > > > > > > -----Original Message----- > > From: Tilman Utz [SMTP:Tilman.Utz@studserv.uni-stuttgart.de] > > Sent: Wednesday, 9 August 2000 17:00 > > To: ginac-list(a)zino.Physik.Uni-Mainz.DE > > Subject: GiNaC with gcc for win32 > > > > Hello all, > > Is it possible to build the GiNaC and cln libraries to libraries which > > can be used for win32 applications? > > I read in the FAQ that it should work with the cygwin package, but as I > > am a newbie on this topic I don't really know how to proceed, e.g. do I > > have to change the makefiles of the cln or GiNaC package. > > Thanks to everyone who is able to answer this maybe trivial question > > Tilman > > > > > > - > > To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of > > "unsubscribe". > - > To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of > "unsubscribe". - To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".

1 0

GiNaC 0.6.4 is on the wire.
by Richard B. Kreckel 10 Aug '00

10 Aug '00

Hello, folx! I justed tagged GiNaC 0.6.4 and uploaded it to the usual places. No new functionality was introduced. During the last weeks we ran the complete check-suite thousands of times and were somewhat surprised to find a couple of nasty bugs. Those have been killed and now the check-suite doesn't seem to find any more. Until somebody decides to re-introduce them... Here is the entry from the NEWS file: * Complete revamp of methods in class matrix. Some redundant (and poor) implementations of elimination schemes were thrown out. The code is now highly orthogonal, more flexible and much more efficient. * Some long standing and quite nasty bugs were discovered and fixed in the following functions: add::normal(), heur_gcd(), sr_gcd() and Order_eval() (thanks to Bernard Parisse). Enjoy -richy. -- Richard B. Kreckel <kreckel(a)ginac.de> <http://www.ginac.de/~kreckel/> - To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".

1 0

RE: GiNaC with gcc for win32
by Billinghurst, David (CRTS) 10 Aug '00

10 Aug '00

GiNaC and cln build out of the box with little (or no) problem on NT4 SP5 using recent cygwin. One of the tests fails occasionally. May be lack of memory - 128 MB doesn't seem enough these days. My laptop is at home, so I don't have the details. Let me know if you have any problems +++++++++++++++++++++++++++++++++++++++++ (Mr) David Billinghurst Comalco Research Centre PO Box 316, Thomastown, Vic, Australia, 3074 Phone: +61 3 9469 0642 FAX: +61 3 9462 2700 Email: David.Billinghurst(a)riotinto.com > -----Original Message----- > From: Tilman Utz [SMTP:Tilman.Utz@studserv.uni-stuttgart.de] > Sent: Wednesday, 9 August 2000 17:00 > To: ginac-list(a)zino.Physik.Uni-Mainz.DE > Subject: GiNaC with gcc for win32 > > Hello all, > Is it possible to build the GiNaC and cln libraries to libraries which > can be used for win32 applications? > I read in the FAQ that it should work with the cygwin package, but as I > am a newbie on this topic I don't really know how to proceed, e.g. do I > have to change the makefiles of the cln or GiNaC package. > Thanks to everyone who is able to answer this maybe trivial question > Tilman > > > - > To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of > "unsubscribe". - To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe".

1 0