From kreckel at ThEP.Physik.Uni-Mainz.DE Sun Jul 2 15:34:20 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Sun, 2 Jul 2000 15:34:20 +0200 (CEST) Subject: Installation on PC using cygwin In-Reply-To: Message-ID: On Thu, 29 Jun 2000, Billinghurst, David (CRTS) wrote: > 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. Thanks for your bugreport. Your patches will be included in the next release. One question: Isn't the macro log2 on cygwin doing exactly what we want so we can say > #ifndef log2 > unsigned log2(unsigned n); > #endif instead of #undefining it? Regards -richy. -- Richard Kreckel From trotts at MIT.EDU Fri Jul 21 00:05:19 2000 From: trotts at MIT.EDU (Issac Trotts) Date: Thu, 20 Jul 2000 18:05:19 -0400 Subject: configuration bug Message-ID: <200007202205.SAA28888@melbourne-city-street.MIT.EDU> 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 From kreckel at ThEP.Physik.Uni-Mainz.DE Fri Jul 21 00:21:10 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Fri, 21 Jul 2000 00:21:10 +0200 (CEST) Subject: configuration bug In-Reply-To: <200007202205.SAA28888@melbourne-city-street.MIT.EDU> Message-ID: Hello Issac, Have you been named after a conference? :-) On Thu, 20 Jul 2000, Issac Trotts wrote: > 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? Something is wrong with your compiler setup, I guess. Maybe you can force the preprocessor to look into /usr/local/include by setting the environment variable CPPFLAGS, like this: $ export CPPFLAGS="-I/usr/local/include" prior to running the configure script. Good luck! Regards -richy. -- Richard Kreckel From trotts at MIT.EDU Fri Jul 21 04:24:47 2000 From: trotts at MIT.EDU (Issac Trotts) Date: Thu, 20 Jul 2000 22:24:47 -0400 Subject: No subject Message-ID: <200007210224.WAA19804@melbourne-city-street.MIT.EDU> 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 From kreckel at ThEP.Physik.Uni-Mainz.DE Wed Jul 26 00:36:53 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Wed, 26 Jul 2000 00:36:53 +0200 (CEST) Subject: Since GiNaC 0.6.2 silently slipped by... Message-ID: ...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 at cvsthep.physik.uni-mainz.de:/home/cvs login enter the password `anoncvs' $ cvs -d :pserver:anoncvs at 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 From parisse at mozart.ujf-grenoble.fr Mon Jul 31 09:39:49 2000 From: parisse at mozart.ujf-grenoble.fr (Parisse Bernard) Date: Mon, 31 Jul 2000 09:39:49 +0200 Subject: 1 bug report & poly. arithmetic with GiNaC Message-ID: <39852D45.315134D@fourier.ujf-grenoble.fr> 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 From kreckel at ThEP.Physik.Uni-Mainz.DE Mon Jul 31 12:30:08 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Mon, 31 Jul 2000 12:30:08 +0200 (CEST) Subject: 1 bug report & poly. arithmetic with GiNaC In-Reply-To: <39852D45.315134D@fourier.ujf-grenoble.fr> Message-ID: Dear Bernard, Thank you for your bugreport and the rest. I tried to download . But it fails, I get three bytes each time. Manually, this is what happens: zino:~$ telnet perso.wanadoo.fr 80 Trying 193.252.19.22... Connected to perso.wanadoo.fr. Escape character is '^]'. GET /bernard.parisse/ginac.tgz ~Connection closed by foreign host. Regards -richy. -- Richard B. Kreckel From parisse at mozart.ujf-grenoble.fr Mon Jul 31 15:26:49 2000 From: parisse at mozart.ujf-grenoble.fr (Parisse Bernard) Date: Mon, 31 Jul 2000 15:26:49 +0200 Subject: 1 bug report & poly. arithmetic with GiNaC References: Message-ID: <39857E99.87688B4E@fourier.ujf-grenoble.fr> "Richard B. Kreckel" a ?crit : > > Dear Bernard, > > Thank you for your bugreport and the rest. I tried to download > . But it fails, I get > three bytes each time. Manually, this is what happens: > zino:~$ telnet perso.wanadoo.fr 80 > Trying 193.252.19.22... > Connected to perso.wanadoo.fr. > Escape character is '^]'. > GET /bernard.parisse/ginac.tgz Sorry, it seems my personnal internet provider has some problems. I have uploaded ginac.tgz to the following ftp server ftp://fourier.ujf-grenoble.fr/pub/hp48/ginac.tgz (ftp seems much more reliable than netscape download) Bernard From kreckel at ThEP.Physik.Uni-Mainz.DE Mon Jul 31 17:52:49 2000 From: kreckel at ThEP.Physik.Uni-Mainz.DE (Richard B. Kreckel) Date: Mon, 31 Jul 2000 17:52:49 +0200 (CEST) Subject: GiNaC and assumptions on variables? In-Reply-To: Message-ID: 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