- GiNaC-devel - ginac.de

GiNaC 1.0.8 now available
by Christian Bauer 31 Mar '02

31 Mar '02

Hello! Following our recent trend of Sunday evening releases we are proud to announce the immediate availability of GiNaC 1.0.8 which you can get from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC Changes include, but are not limited to - Improvements in memory usage of the expand() methods. Hm, wait... that's the only change!? <searches CVS logs> Aha, sorting of vector<expair> is a little faster, and the namespace fix for is_ex_the_function() is in. Alas, long gone now are the days of 0.9.x where changelog pages filled screen after screen... Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

Possible memory leak? (was: update on fast mult benchmark (fwd))
by Pearu Peterson 29 Mar '02

29 Mar '02

Hi! I have tried to run Richard Fateman's multiplication benchmark also with GiNaC (1.0.2,1.0.6) but unsuccefully because expand() method starts to eat large amounts of memory so that I had to kill the process. Could this indicate a possible memory leak in GiNaC? Any other ideas? Here is my test program: #include <ginac/ginac.h> using namespace GiNaC; int main() { symbol x("x"), y("y"), z("z"); ex r = (ex(power(1 + x + y + z, 20 ))).expand(); ex r1 = r+1; ex m = (r*r1).expand(); return 0; } Regards, Pearu ---------- Forwarded message ---------- Date: Fri, 22 Mar 2002 16:01:01 -0800 From: Richard Fateman <fateman(a)cs.berkeley.edu> Newsgroups: sci.math.symbolic Subject: update on fast mult benchmark I've added some more programs. It looks like this now. MockMMA 5.8 seconds (including 2.1 in GC) Macsyma (in ACL 6.1) 6.9 seconds (including 2.0 in GC) Hashing 8.6 seconds (including 2.2 in GC) Fermat 9.2 seconds Macsyma (maxima5.5) 32.0 seconds (? GC not reported, second trial) Macsyma (commercial) 37.5 seconds (including 29.78 in GC) Macsyma (maxima5.5) 53.5 seconds (? GC not reported, first trial) Maple7 50.0 seconds (? GC, it was slower on 2nd trial) Mathematica 4.1 82.3 seconds (? it was slower on 2nd trial) MuPad 1.4.2 Pro 118.6 seconds for multiplying the expanded version of (1+x+y+z)^20 by itself. details on http://www.cs.berkeley.edu/~fateman/papers/fastmult.pdf comments invited. RJF

4 13

Problem with `is_ex_the_function'
by Roberto Bagnara 22 Mar '02

22 Mar '02

Dear all, there is a bug in macro `is_ex_the_function' defined in ginac/function.h. As it is now, the macro only works if the file is included in a context where using declarations are in effect, since a couple of GiNaC:: qualifications are missing. I enclose a patch fixing the problem. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it diff -ru GiNaC-1.0.7.orig/ginac/function.h GiNaC-1.0.7/ginac/function.h --- GiNaC-1.0.7.orig/ginac/function.h Sun Jan 27 18:39:38 2002 +++ GiNaC-1.0.7/ginac/function.h Fri Mar 22 16:18:43 2002 @@ -416,7 +416,7 @@ } #define is_ex_the_function(OBJ, FUNCNAME) \ - (is_exactly_a<GiNaC::function>(OBJ) && ex_to<GiNaC::function>(OBJ).get_serial() == function_index_##FUNCNAME) + (GiNaC::is_exactly_a<GiNaC::function>(OBJ) && GiNaC::ex_to<GiNaC::function>(OBJ).get_serial() == function_index_##FUNCNAME) } // namespace GiNaC

1 0

Annoying warning (II attempt)
by Roberto Bagnara 22 Mar '02

22 Mar '02

Dear all, there is a warning about an unused parameter due to line 84 in basic.h (GiNaC 1.0.7): virtual void destroy(bool call_parent) { } Having seen the warning two million times I thought it was better to report it ;-) Actually, I reported this problem already on February 2 but it seems I was not very successful. This time I enclose a patch fixing the problem. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it diff -ru GiNaC-1.0.7.orig/ginac/basic.h GiNaC-1.0.7/ginac/basic.h --- GiNaC-1.0.7.orig/ginac/basic.h Thu Jan 24 23:28:20 2002 +++ GiNaC-1.0.7/ginac/basic.h Fri Mar 22 16:35:07 2002 @@ -81,7 +81,7 @@ tinfo_key = other.tinfo_key; } /** For use by dtor and assignment operator. */ - virtual void destroy(bool call_parent) { } + virtual void destroy(bool /* call_parent */) { } // other ctors /** ctor with specified tinfo_key */

1 0

And GiNaC-1.0.7 shall be made legion...
by Richard B. Kreckel 18 Mar '02

18 Mar '02

Its numbers shall be increased a thousand thousand fold. The din of a million keyboards like unto a great storm shall cover the earth, and the followers of Mammon shall tremble. adapted from The Book of Mozilla, 3:31 (Red Letter Edition)

1 0

ginac.m4 and cln.m4
by Roberto Bagnara 20 Feb '02

20 Feb '02

Hi there, there are problems with ginac.m4 and cln.m4 with autoconf 2.52 and following (the nature of the problems and their cure is described in autoconf's documentation). Please find enclosed a patch that solves everything. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it diff -rcp2N old/cln.m4 new/cln.m4 *** old/cln.m4 Wed Feb 20 08:43:47 2002 --- new/cln.m4 Wed Feb 20 08:42:33 2002 *************** dnl AC_PATH_CLN([MINIMUM-VERSION, [ACTIO *** 11,15 **** dnl Test for installed CLN library, and define CLN_CPPFLAGS and CLN_LIBS dnl ! AC_DEFUN(AC_PATH_CLN, [dnl dnl Get the cppflags and libraries from the cln-config script --- 11,15 ---- dnl Test for installed CLN library, and define CLN_CPPFLAGS and CLN_LIBS dnl ! AC_DEFUN([AC_PATH_CLN], [dnl dnl Get the cppflags and libraries from the cln-config script diff -rcp2N old/ginac.m4 new/ginac.m4 *** old/ginac.m4 Wed Feb 20 08:43:17 2002 --- new/ginac.m4 Wed Feb 20 08:42:33 2002 *************** *** 8,15 **** # Shamelessly stolen from Owen Taylor ! dnl AM_PATH_GINAC([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]]) dnl Test for GiNaC, and define GINACLIB_CPPFLAGS and GINACLIB_LIBS dnl ! AC_DEFUN(AM_PATH_GINAC, [dnl dnl Get the cppflags and libraries from the ginac-config script --- 8,15 ---- # Shamelessly stolen from Owen Taylor ! dnl AC_PATH_GINAC([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]]) dnl Test for GiNaC, and define GINACLIB_CPPFLAGS and GINACLIB_LIBS dnl ! AC_DEFUN([AC_PATH_GINAC], [dnl dnl Get the cppflags and libraries from the ginac-config script

2 1

ginsh compile problem
by keith.briggs＠bt.com 14 Feb '02

14 Feb '02

ginac-1.0.5 fails to compile ginsh using: redhat 6.0 gcc-3.0.3 cln-1.1.4 readline-2.2.1-5 > > Making all in ginsh > > make[2]: Entering directory `/home/kbriggs/GiNaC-1.0.5/ginsh' > > sed -n -f ./ginsh_fcn_help.sed <ginsh.1 >ginsh_fcn_help.h > > sed -n -f ./ginsh_op_help.sed <ginsh.1 >ginsh_op_help.h > > source='ginsh_parser.cc' object='ginsh_parser.o' libtool=no \ > > depfile='.deps/ginsh_parser.Po' tmpdepfile='.deps/ginsh_parser.TPo' \ > > depmode=gcc3 /bin/sh ../depcomp \ > > /usr/local/bin/g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac > > -DIN_GINAC -I/usr/local/include -g -O2 -c -o ginsh_parser.o `test -f > > ginsh_parser.cc || echo './'`ginsh_parser.cc > > /usr/include/readline/readline.h: In function `char** > fcn_completion(const > > char*, int, int)': > > /usr/include/readline/readline.h:232: too many arguments to function > `char** > > > > completion_matches()' > > ginsh_parser.yy:769: at this point in file > > /usr/include/readline/readline.h:232: too many arguments to function > `char** > > > > completion_matches()' > > ginsh_parser.yy:779: at this point in file > > make[2]: *** [ginsh_parser.o] Error 1 > > make[2]: Leaving directory `/home/kbriggs/GiNaC-1.0.5/ginsh' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/kbriggs/GiNaC-1.0.5' > > make: *** [all] Error 2 > > > > Dr. Keith M. Briggs > > Senior Mathematician, Complexity Research, BTexact Technologies > > > > email: Keith.Briggs(a)bt.com > > phone: +44(0)1473 work: 641 911 home (new!): 610 517 fax: 647 410 > > web: www.btexact.com/people/briggsk2/ > > mail: Keith Briggs, Antares 2pp5, Adastral Park, Martlesham, Suffolk > > IP5 3RE, UK > >

1 0

FAQ
by Richard B. Kreckel 04 Feb '02

04 Feb '02

Hi, Our FAQ [1] was giving the impression that tree-traversals for complex operations are best being written as functions that recursively call themselves and contain lots of silly little ifs that distinguish between the different object types. This was rubbish. I have polished up an old example (an actual prototype of a simplifier in a certain domain) and rewritten the items "How do I simplify things like sin^2+cos^2 to 1?" and "How do I write a tree-traversal algorithm?" from scratch to take a more elegant and more powerful point of view. If (after careful study, please) people find something unclear therein or even actual errors, I would very much like to hear about that. I am confident that people writing applications in GiNaC will benefit greatly from these these two rewritten sections. For the curious, the old FAQ is still available [2]. enjoy! -richy. [1] <http://www.ginac.de/FAQ.html> [2] <http://www.ginac.de/FAQ_old.html> -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Annoying warning
by Roberto Bagnara 03 Feb '02

03 Feb '02

Dear all, there is a warning about an unused parameter due to line 84 in basic.h (GiNaC 1.0.5): virtual void destroy(bool call_parent) { } Having seen the warning a million times I thought it was better to report it ;-) All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

3 4

Re: Alternative bernoulli(const numeric &)
by Markus Nullmeier 01 Feb '02

01 Feb '02

From: Richard B. Kreckel <kreckel(a)thep.physik.uni-mainz.de> > Hmm, I think a simple cast to long would get the job done, in the same > manner as the numeric ctors from builtin types work. Yes, a change to `long' would push the limit for even arguments to 65534. However I think the real problem lies in the "philosophical" nature of my question. I guess nobody will want to calculate Bernoulli numbers this big (the limit of the 1.0.3 code seems to be 8190). Thus I think things could be left as they are, since the CLN manual hints that conversions from `long' are less efficient. By altogether abolishing the theoretical limit and letting CLN calculate (p3-i)*(p2-i), we would slow the procedure down by some per cent without any real gain. But I suppose this road should be taken if 23168 did become an issue, like if (p < 23168) { normal_inner_loop; } else { slow_inner_loop_with_CLN; } If you like this better I can make a patch. Markus

3 11