- GiNaC-devel - ginac.de

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

0.6.0
by Keith Briggs 18 May '00

18 May '00

Dear ginac-bugs(a)ginac.de, I tried to install 0.6.0 on my RH6.0 linux system. I got these errors: Making install in reference make[2]: Entering directory `/home/install/GiNaC-0.6.0/doc/reference' make[3]: Entering directory `/home/install/GiNaC-0.6.0/doc/reference' make[3]: Nothing to be done for `install-exec-am'. /bin/sh ../../mkinstalldirs /usr/local/share/doc/GiNaC/reference /usr/bin/install -c -m 644 ./*.html /usr/local/share/doc/GiNaC/reference/*.html /usr/bin/install: ./*.html: No such file or directory make[3]: *** [install-data-local] Error 1 make[3]: Leaving directory `/home/install/GiNaC-0.6.0/doc/reference' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/home/install/GiNaC-0.6.0/doc/reference' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/install/GiNaC-0.6.0/doc' make: *** [install-recursive] Error 1 Also, after `make install' I found that my programs would not compile because version.h had not been copied to /usr/local/include/ginac. I had to do this by hand, then my programs would compile. Also, I have a problem with cout<<(log(1+2*x)/2).series(x==0,n); which does not produce its output in ascending order of powers. Thank you, 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 | | www.bt.com | personal homepage: www.labs.bt.com/people/briggsk2/ | +-------------------------------------------------------------------+

2 1

GiNaC 0.6 is on the wire!
by Richard B. Kreckel 12 May '00

12 May '00

Good morning everybody! We loudly present a new release of the GiNaC framework for symbolic computation within your favorite programming language. Please hurry up and grab your copy from <http://www.ginac.de/Download.html>. Make sure you read the file NEWS to see that we did an awful job trying to break your existing code! Also included in make-target check are some tests invented by R. Lewis and M. Wester, carefully crafted by skilled coders to successfully overheat your CPU and bring down your machine within minutes! Interfacing GiNaC with Cint is also progressing nicely and if nobody angers the gods of computing the world will soon see a fully integrated symbolic C++ interpreter! \begin{SalespersonSpeak} INCREASE PRODUCTIVITY WITH A PROVEN TOOL GiNaC 0.6 provides the right set of tools so that you can be more productive, more effective, and solve more problems. Use GiNaC 0.6 in all phases of your technical projects. Instead of relying on several separate and expensive software packages, GiNaC 0.6 provides a single computing environment for defining and setting up models, analyzing the results both numerically and graphically, and creating technical reports for publication, or e-publication. TRUST THE INNOVATION LEADERS Countless users all over the world have chosen GiNaC's technology as their preferred platform for solving, analyzing, and designing models in their computational projects. Our customers include virtually all major universities and research institutions, and countless corporations. These customers understand that the complexities of modern analytical computation demand the highest levels of computational excellence. With GiNaC 0.6, we continue to earn the trust of customers by delivering new and robust technology. GiNaC 0.6 is the result of over a thousand person-days of advanced research and development. With ignorant quality assurance practices and casual use of customer feedback through nonexistent beta programs, you can have confidence that the results from GiNaC 0.6 will be reliable and accurate. \end{SalespersonSpeak} We hope to see you again soon when we release GiNaC 0.7 and rip our announcement from another major competitor in the field. :-) Happy hacking -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

[FYI] the potential of GMP -> CLN -> GiNaC boosts
by Richard B. Kreckel 02 May '00

02 May '00

Hi, Since GMP3 has been released we are now in the process to adapt CLN to make use of that new library. While GMP3 seems to be much faster than GMP2 (largely because of the support of common new processors like PPro and also due to some improved algorithms with better asymptotic behaviour) and CLN does see a large chunk of this improvement I have the impression that most common symbolic computations don't actually benefit too much from this. Just because I was curious, I have made a preliminary statically linked GiNaC suite of timings, once with the old CLN using GMP2 and once with a CLN using the new GMP3. The results are interesting in a sense that they don't show much improvement. I have marked the tests which make heavy use of the class GiNaC::numeric (and thus are expected to run faster now) with an asterisk, the others with a dash: timing commutative expansion and substitution.... passed - size: 25 50 100 200 w/GMP2: time/s: 0.03 0.16 0.67 2.99 w/GMP3: time/s: 0.04 0.15 0.66 3.01 timing Laurent series expansion of Gamma function.... passed - order: 10 15 20 25 w/GMP2: time/s: 0.130 0.709 3.26 12.65 w/GMP3: time/s: 0.119 0.719 3.209 12.48 timing determinant of univariate symbolic Vandermonde matrices.... passed - dim: 4x4 6x6 8x8 10x10 w/GMP2: time/s: 0.002 0.02 0.299 2.91 w/GMP3: time/s: 0.003 0.02 0.299 2.88 timing determinant of polyvariate symbolic Toeplitz matrices.... passed - dim: 5x5 6x6 7x7 8x8 w/GMP2: time/s: 0.035 0.190 0.959 4.15 w/GMP3: time/s: 0.036 0.179 0.930 4.08 w/GMP2: w/GMP3: timing Lewis-Wester test A (divide factorials). 0.35 0.35 * timing Lewis-Wester test B (sum of rational numbers). 0.027 0.027 * timing Lewis-Wester test C (gcd of big integers). 0.45 0.45 * timing Lewis-Wester test D (sum of rational fcns). 0.00085 0.00086 - timing Lewis-Wester test E (sum of rational fcns). 0.00082 0.00081 - timing Lewis-Wester test F (gcd of 2-var polys). 0.095 0.095 ? timing Lewis-Wester test G (gcd of 3-var polys). 3.35 3.21 ? timing Lewis-Wester test H (det of 80x80 Hilbert). 10.88 10.30 * timing Lewis-Wester test I (invert rank 40 Hilbert). 4.10 3.97 * timing Lewis-Wester test J (check rank 40 Hilbert). 1.90 1.86 * timing Lewis-Wester test K (invert rank 70 Hilbert). 26.34 25.29 * timing Lewis-Wester test L (check rank 70 Hilbert). 10.96 10.70 * timing Lewis-Wester test M1 (26x26 sparse, det). 0.46 0.46 - timing Lewis-Wester test O1 (three 15x15 dets, average)... 49.51 49.31 - timing Lewis-Wester test P (det of sparse rank 101). 5.49 5.49 * timing Lewis-Wester test P' (det of less sparse rank 101). 10.02 9.69 * timing Lewis-Wester test Q (charpoly(P)). 145.71 144.10 * timing Lewis-Wester test Q' (charpoly(P')). 293.92 289.26 * It's embarassing that the four first tests show a common pattern: the new library runs slightly faster with large problem sizes and slower with small once. It's perfectly reproducible. Can anybody suggest a possible explanation for this? Cheers -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0