August 2000 - GiNaC-devel

polynomial arithmetic over ginac
by Parisse Bernard 23 May '01

23 May '01

I have now a little bit improved the package of my polynomial and rational fractions utilities over GiNaC (0.6.4) It provides now gcd normalization, factor (square-free and rational roots), partfrac & integrate (assuming factor works on the denominator), for example: integrate '1/(x^4-1)^5' returns -1155/8192*log(1+x)-1155/4096*atan(x)+1155/8192*log(-1+x)+1/2048*(-893*x-1375*x^9+1755*x^5+385*x^13)*(-1+x^4)^(-4) # Time for (integrate)0.04 You can retrieve and test it at ftp://fourier.ujf-grenoble.fr/pub/hp48/giac.tgz Bye, Bernard Parisse

4 9

sqrfree
by Parisse Bernard 11 Mar '01

11 Mar '01

Hi, Doing some tests with square-free factorization, I believe I have found a bug. Let e by (x+y)^2*(x-y) expanded and call sqrfree(e,x). You do not get the original expression, it remains expanded. If y is replaced by 1 it seems it works. Bernard

3 3

factorization with GiNaC
by Parisse Bernard 23 Aug '00

23 Aug '00

Hello, I have uploaded at ftp://fourier.ujf-grenoble.fr/pub/hp48/giac.tgz the latest version of my polynomial library with a beta version of a factorization algorithm. See README for installation, and try sh test.factor to test the factorization. Now waiting for bug reports:-) Bernard

1 0

Cint 5.14.45
by Richard B. Kreckel 12 Aug '00

12 Aug '00

I just found an error in GiNaC's INSTALL file. The last line should read > 5.14.45 | compiles fine, works like a charm instead of < 5.14.45 | compiles fine, still some weirdnesses during execution I had a wrong link when I tried it. :-) -richy. -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

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