- GiNaC-devel - ginac.de

can't subs(lst) on a function
by Chris Dams 18 May '02

18 May '02

Hello, I use GiNaC version 1.0.8 (and gcc version 3.0.1) and found out that the only subs-method that can be used with an exprseq is ex subs(const lst & ls, const lst & lr, bool no_pattern = false) The consequence seems to be that (since a function is derived from a exprseq) that I am allowed to write ex e=sin(x*y+x); cout << e.subs(lst(x==-2,y==4)) << endl; which gives the expected result sin(-10), but I am not allowed to write cout << sin(x*y+x).subs(lst(x==-2,y==4)) << endl; because this causes the error: test.C: In function `int main(int, char**)': test.C:9: no matching function for call to `GiNaC::function::subs(GiNaC::lst) const' /usr/local/include/ginac/exprseq.h:84: candidates are: virtual GiNaC::ex GiNaC::exprseq::subs(const GiNaC::lst&, const GiNaC::lst&, bool = false) const I think another subs-method should be added to exprseq so that this error no longer occurs. Greetings, Chris Dams

2 1

Fibonacci Hashing revisted
by Richard B. Kreckel 02 May '02

02 May '02

Hi, As a sequel to that thread about Fateman's fast mult benchmark I have growing qualms about our hashcode generation. First, the observations made in basic::compare(const basic&): 1) Hardly ever a hash collision between different types occur while hash collissions between different types are very frequent. This suggests that something is better in one case than in the other. 2) Of course, there are unavoidable collisions when two equal objects are compared. These amount to about 2/3 of all cases. In other words: 1/3 of all collisions result in a call to compare_same_type() and a subsequent traversal. This seems way too much, given a hash-space of 31 bit. (More on that later.) 3) Applying a unary ~ on the hash-values of class numeric (i.e. inverting all bits) reduces the number of collisions by about 20% and results in a speedup of about 10%. As a crude estimate we could deduce a potential speedup factor two(!), given an ideal collision-free hashing. No, I don't expect this to happen, but maybe 50% should be doable. What's wrong with our hashing? I am still trying to find out. Right now, what I have is this: a) CLN's hashes are sub-optimal for our purposes. Basically, they seem to populate too few bits for the frequent small numbers. Maybe that can be improved. This results in some funny collisions due to some fundamental properties of the binary number system. That should be easy to improve even without changing anything in CLN. (I hesitate doing this in CLN since I have no idea what other people are using cln::equal_hashcode() for.) b) We rotate the bits in expairseq::calchash() before xoring with the next element. I doubt this makes sense. The rotation is done in order to have h(h(X),h(Y)) be different from h(h(Y),h(X)). This looks superfluous to me, since the elements of expairseq are canonicalized anyways when the hashing occurs so commutativity should be a non-issue. c) The split-up of our hash space into two halves, one for numeric hashes and one for non-numeric hashes effectively throws away one valuable bit. As far as I can recall, there were some historic reasons why this was done (initially, we didn't have hashes for numeric types). However, if one would like to try out the hashtab-based class expairseq again, then the implementation seems to demand that split-up. See expairseq::calc_hashindex(const ex&) for the only occurrence of the is_a_numeric_hash() macro. Hmm, I fail to see the theoretical reason why hashtabs need such a trick. Since I very much like to introduce one clean globalized hash space, I need to remove this code. Is it really needed? Why? Call for help: Does anyone know more about this stuff? (Alex, maybe you, since you wrote it long ago?!?) Regards -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

2 3

Re: Form is really slow and fast for me. What could this mean?
by FORM Administrator 17 Apr '02

17 Apr '02

In the single line example FORM will definitely not look for common subexpressions and try to evaluate them separately. That is completely against its philisophy. There you would have to help it a bit. Note that it will always be possible to invent benchmarks like this that give poor performance. Actual performance is what counts most. Cheers Jos Vermaseren

1 0

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