- GiNaC-devel - ginac.de

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/>

1 0

Tutorial spello
by keith.briggs＠bt.com 10 Aug '00

10 Aug '00

> Now that all the ingrediences for cos have been set up, ^^ ingredients Keith Dr. Keith M. Briggs, Complexity Research Group, BT Research Labs. Adastral Park admin2 pp5, Martlesham Heath, IP5 3RE, Suffolk, UK Tel. 01473 641 911 Fax. 01473 647 410. Home tel: 01473 625 972 personal homepage: www.labs.bt.com/people/briggsk2/

1 0

memory hole in egcs or ginac
by Paul Grayson 03 Aug '00

03 Aug '00

The following program uses up all of my RAM in about 20 seconds: ------------------------------ #include <ginac/ginac.h> using namespace GiNaC; int main() { while(1) symbol x("x"); } ------------------------------ ...and here's how I compile it: (using an fresh-out-of-the-box ./configure'd GiNaC) ------------------------------ capibara$ c++ -dumpversion egcs-2.91.66 capibara$ c++ -dumpmachine i386-slackware-linux capibara$ c++ try.cc -lcln -lginac -o try capibara$ try [memory usage goes up and up...] ------------------------------ If I compile it with this line instead, I have no similar problem: while(1) basic x = symbol("x"); ...any ideas? Am I confused about C++ (likely), or do I just have an old, buggy version of egcs, or is there a problem here? Thanks -Paul

2 1

Re: GiNaC and assumptions on variables?
by Richard B. Kreckel 01 Aug '00

01 Aug '00

On 31 Jul 2000, Paul Grayson wrote: > Hi, you don't have any sort of a feedback/suggestions/questions > mailing address, and I didn't know if writing to devel was a good > idea, so here's my question: Hi Paul. Writing to ginac-devel is IMHO a good idea. It makes ideas known to others and somebody might have already thought about it, have an idea how to do this or have a veto against that. I CC this email there. (And I should set up mhonarc RSN...) > I'm an undergraduate in physics at MIT, and I just started taking a > look at GiNaC after getting frustrated with Mathematica and Maple. > Needless to say, it was very refreshing to see that I could do math in > a reasonable programming environment. Basically I'm interested in > getting GiNaC to do some classical perturbation theory for me, which > basically will involve going through a bunch of integration and > simplification of large expressions. > > The integration I can handle pretty easily myself (all terms are > prop. to cos(x)^n*sin(x)^m). In fact, I think GiNaC will do a much > better job at this than Maple or Mathematica, which both get *really* > bogged down when I try to integrate ~100 terms with complicated > constant factors. When a CAS computation takes forever, I have no way > to discover why; GiNaC will let me analyze the computation like any > computer program, and fix it. For simplification, however I really > need some way to work with constants that are known to have values in > a certain range. For example, given that x is real and x>0, we know > sqrt(x*x) -> x. Though this example is trivial, with larger > expressions in many variables automatic simplifcation *with > assumptions on variables* can be quite useful. It's very frustrating > when the computer doesn't even know that my variables are all *real*! > > Both Maple and Mathematica have added this feature to their most > recent versions: In Maple V6, I can type > > assume(x>0); > sqrt(x*x); > > and get 'x' as a result. I read through the GiNaC documentation, and > didn't see any obvious way to do this. However, you make various > statements in the docs that indicate that there are many hidden ways > to simplify expressions in GiNaC --- do you have any methods in mind > for performing these kinds of simplifications? If not, do you see any > reason that I shouldn't/couldn't implement this feature? Would you > be interested in giving me some guidance so that, if I added this, I > could get it incorporated back into the main GiNaC distribution? > > Thanks, > -Paul What you want to do doesn't sound impossible to me. However, for my own part, I don't think I do need this kind of feature and so won't be able to help much. Guidance is possible, though. And no, nothing like this has been implemented yet. Adding assumptions to expressions throws up a couple of questions: Where do you stick assumption-tags? A pointer to something in class ex might slow it down somewhat, though this needs to be tested. I think ex would be the way where to store it. The alternative would be a protected variable in class basic. You need to think about how to evaluate those tags. The trivial example you give suggests that each class' eval() function should check for members' property-tags, it could read them via the .info() method. (The info_flags class might need some careful restructuring, if this wants to be going into production use. It is pretty much hacked together.) If it gets in the way in the .eval() function, an alternative would be to add this checking to another evaluation-method. It can soon get very involved as soon as more than one variables are involved. There is some literature about this and one should carefully check what Maple does here. Maybe it is discouraging, maybe it is stimulating, but please have a look at this Maple session: zino:~/projects/GiNaC/ginac$ maple |\^/| Maple V Release 4 (Universitaet Mainz) ._|\| |/|_. Copyright (c) 1981-1996 by Waterloo Maple Inc. All rights \ MAPLE / reserved. Maple and Maple V are registered trademarks of <____ ____> Waterloo Maple Inc. | Type ? for help. > interface(version); TTY Iris, Release 4, DEC ALPHA UNIX, Apr 28, 1997 > assume(x>0); > sqrt(x^2); x~ > assume(y>0); > about(x+y); x+y: Error, (in ConvertProperty) too many levels of recursion > about(sqrt((x+y)^2)); x+y: Segmentation fault I don't know if Maple6 performs better in this respect. If you are still interested, I can see if I find some pointers into the literature about such things and send them to you. It definitely requires some thinking before one can start hacking. Regards -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

2 1

1 bug report & poly. arithmetic with GiNaC
by Parisse Bernard 31 Jul '00

31 Jul '00

Hello, First I have a bug report: inifcns.cpp, function Order_eval, l.382, O(c)=O(1) is not true if c=0 hence the code slice should be ... if (is_ex_exactly_of_type(x, numeric)) { // O(c)=O(1) BUG! except if c=0, O(0)=0 if (x==0) return(x); else return Order(_ex1()).hold(); } else if (is_ex_exactly_of_type(x, mul)) { ... I am currently working on an implementation on polynomial arithmetic using tensors to represent multivariate polynomials instead of ex, in order to be more efficient. If people are interested, they can get http://perso.wanadoo.fr/bernard.parisse/ginac.tgz The current version implements GCD (gcdheu and sub-resultant algorithm) as well as extended GCD. Simplification might be much faster using test1.cc than the built-in normal function of GiNaC, for example if you try test1.cc on input like 1/x+1/(x-1)+1/(x-2)+...+1/(x-10) The archive should be untarred in the GiNaC-0.6.3 directory, it contains 3 modified GiNaC 0.6.3 files: inifcns.cpp (bug above fixed) power.h (members basis and exponent declared public to be used by qnormal.cc) expairseq.h (member epvector declared public). The other files are index.h/index.cc: index class to represent the powers of the variables in a monomial tensor.h: template class for multivariate polynomials of a given field qnormal.h/qnormal.cc: instantiation of tensor.h with numeric coeff test1.cc: test the simplification function test2.cc: instantiation and test of the extended GCD algorithm. Each file can be compiled by the compile command inside emacs. Best regards, Bernard Parisse, Institut Fourier, 100 rue des maths, Universite de Grenoble I, F-38402 St Martin d'Hères

2 2

Since GiNaC 0.6.2 silently slipped by...
by Richard B. Kreckel 26 Jul '00

26 Jul '00

...here is GiNaC 0.6.3. You may download it from the usual ftp-site. We also provide read-only access through anonymous CVS now! You may set up your local copy somehow like this: $ cvs -d :pserver:anoncvs@cvsthep.physik.uni-mainz.de:/home/cvs login enter the password `anoncvs' $ cvs -d :pserver:anoncvs@cvsthep.physik.uni-mainz.de:/home/cvs -z 9 co GiNaC and later keep up-to-date by simply saying 'cvs update' in your GiNaC directory. Here is what's new in version 0.6.3 (0.6.2 only brought changes related to GiNaC-cint): 1 Derivatives are now assembled in a slightly different manner (i.e. they might 'look' different on first sight). Under certain circumstances this can result in a dramatic speedup because it gives hashing a better chance, especially when computing higher derivatives. 2 Some series expansions of built-in functions have been reengineered. 3 The algorithm for computing determinants can be chosen by the user. See ginac/flags.h and ginac/matrix.h. 4 The Dilogarithm (Li2) now has floating point evaluation, derivative and a proper series expansion. 5 Namespace 'std' cleanly disentangled, as demanded by ISO/EIC 14882-1998(E). 6 Some minor bugfixes, one major lsolve()-bugfix and documentation updates. Item 5 should facilitate a transition to GCC3 once the first beta versions become available. The current status of that project is too fragile to give it a real test. Note also, that Cint 5.14.44 (the current release) seems to be rather broken. For those interested in GiNaC-Cint: please use release 5.14.41, i.e. the 'previous' one, to be found on our FTP-server. And no, there were no releases in between, sigh. Sex and drugs and algebra -richy. -- Richard B. Kreckel <kreckel(a)ginac.de> <http://www.ginac.de/~kreckel/>

1 0

None
by Issac Trotts 21 Jul '00

21 Jul '00

First, let me thank you for making available this wonderful library. The bug that I'm reporting is actually a bug in gcc 2.95.2, which unfortunately #defines log2 in math.h instead of using inline functions. This conflicts with your perfectly reasonable attempt to overload log2 in utils.h. So, in order to get GiNaC to compile, I had to replace unsigned log2(unsigned n); with #ifdef log2 #undef log2 #endif unsigned log2(unsigned n); -Issac

1 0

configuration bug
by Issac Trotts 21 Jul '00

21 Jul '00

I'm trying to compile GiNaC on a PC running Windows 2000 with the Cygwin UNIX utilities, but there seems to be a problem with the directories. When I compile CLN and make install, the CLN files get installed in /usr/local/lib and /usr/local/include by default. This seems like a sensible place to put the files, but when I run ./configure in the GiNaC directory, it tells me configure: error: cannot find header for Bruno Haible's CLN This message goes away if I install the CLN files in /usr/include and /usr/lib, but I don't like to do it this way. Do you know how I can make the configure script look for the CLN files in their default location in /usr/local? Thanks, Issac

2 1

Installation on PC using cygwin
by Billinghurst, David (CRTS) 02 Jul '00

02 Jul '00

I have just installed ginac-0.6.2 on a PC under NT4SP5 using gcc-2.95/cygwin (http://sourceware.cygnus.com/cygwin) There were two minor problems fixed by patches below. 1. cygwin defines a macro log2, which confuses ginac function in utils 2. a builddir != srcdir cannot find ginsh/*.sed files After these fixes the build and the checks were OK. +++++++++++++++++++++++++++++++++++++++++ (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.au --- ginsh/Makefile.am.orig Sat Feb 5 02:03:58 2000 +++ ginsh/Makefile.am Thu Jun 29 09:53:56 2000 @@ -10,10 +10,10 @@ EXTRA_DIST = $(man_MANS) ginsh_parser.h ginsh_fcn_help.sed ginsh_op_help.sed # files created by sed scripts -ginsh_fcn_help.c: ginsh.1 ginsh_fcn_help.sed - sed -n -f ginsh_fcn_help.sed <$< >$@ +ginsh_fcn_help.c: ginsh.1 $(srcdir)/ginsh_fcn_help.sed + sed -n -f $(srcdir)/ginsh_fcn_help.sed <$< >$@ -ginsh_op_help.c: ginsh.1 ginsh_op_help.sed - sed -n -f ginsh_op_help.sed <$< >$@ +ginsh_op_help.c: ginsh.1 $(srcdir)/ginsh_op_help.sed + sed -n -f $(srcdir)/ginsh_op_help.sed <$< >$@ ginsh_parser.o: ginsh_fcn_help.c ginsh_op_help.c --- ginac/utils.h.orig Tue Jun 27 23:20:32 2000 +++ ginac/utils.h Wed Jun 28 21:12:29 2000 @@ -45,6 +45,7 @@ * signal that ordinary Taylor expansion is safe. */ class do_taylor {}; +#undef log2 unsigned log2 (unsigned n); int compare_pointers(const void * a, const void * b);

2 1

throwing aborts, or: libtool sucks, or: slink sucks even more
by Richard B. Kreckel 30 May '00

30 May '00

Hi everybody, The issue of the nasty crashes whenever something is thrown internally (as in .normal(), if the heuristic algorithm failed or in .series() for functions with poles) came up last week. Finally it is becoming clear what's happening. series(tgamma(x),x==0,1) crashed reproducibly when linked dynamically, either in ginsh, ginaccint or elsewhere. Let me explain what's happening. So I am no longer to blame. :-) GiNaC 0.6.1 got an updated libtool from FSF (1.3.4 instead of 1.3.3) and that libtool has changed it's behaviour for linking: $ libtool --mode=link c++ ... uses $CC for linking instead of c++, as it used to be. Libtool's documentation does have something to say about this: > [...] running the C++ compiler directly may lead to problems related > with inter-library dependencies. > > The conclusion is that libtool is not ready for general use for C++ > libraries.[...] > > Furthermore, you'd better find out, at configure time, what are the C++ > Standard libraries that the C++ compiler will link in by default, and > explicitly list them in the link command line. Hopefully, in the future, > libtool will be able to do this job by itself. I am somewhat clueless what those `problems related with inter-library dependencies' might be (there seems to be a gap in the mailing list archives). Well, the day before yesterday they have released libtool 1.3.5 but that doesn't change much. Anyhow, the trouble starts only when you use jurrasic compilers. And Debian/Slink does precisely this: gcc (used for linking) is 2.7.2.3 while c++ (used for compiling) is 2.91.60. Makes the solution pretty obvious: Just exporting CC=egcc prior to configuring solves all problems. Big deal. Or upgrading to Potato (if they manage to release it some lucky day). Happy hacking -rbk. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 1