- GiNaC-devel - ginac.de

Q: What comes after nine?
by Richard B. Kreckel 24 Jul '02

24 Jul '02

A: ten! Seriously, what else did you expect? So, here goes GiNaC version 1.0.10... (*) ...incorporating bug fixes only, at least unless you haven't been using undocumented internal features. (Hi Markus!) Happy compiling -richy. (*) Yep, it's Debian/woody approved! -- Richard B. Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

gTybalt 0.1.0
by Stefan Weinzierl 17 Jul '02

17 Jul '02

Monday morning, 7 am, a new week starts: On the first day of the new week you decide to install the new compiler gcc 3.1. On the second day, you downloaded and installed the CLN library, version 1.1.5. On the third day you got GiNaC, version 1.0.9. On the fourth day you played around with Root, version 3.03.06. On the fifth day you decided, that you would like to have TeXmacs 1.0.0.9 as editor. Now it's Saturday night, you look back at what you have done this week. You know that all your packages work well, but you are still not satisfied ! You ask for more ! Now it's time to download gTybalt 0.1.0 from http://www.fis.unipr.it/~stefanw/gtybalt.html, which will make all your packages work together. Epilogue: Sunday morning: Some people just relax, others download nestedsums 1.1.0 and calculate loop integrals in quantum field theory with it.

1 0

expression input
by Vincent Demarcus 12 Jul '02

12 Jul '02

Hi guys, first, thanks for your great package! I am trying to let users input expressions with matrix indices in their expressions (like A.i). I order to try this feature, I wrote a simple program (see attached file try.cpp) (compiled with gcc) the bulk of the program consist in: ex e("2*S.j+n", lst(S,j,n)); //(S is a symbol, j an idx, n a symbol) cout << "ok! :" << e << endl; I am getting the result: ok! :2*S which is wrong in my opinion. Am I doing something wrong? Are there ways to get around this problem? Thanks for your help #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main (){ symbol j_sym("j"); symbol n("n"); idx j(j_sym,n); symbol S("S"); try { ex e("2*S.j+n", lst(S,j,n)); cout << "ok! :" << e << endl; } catch (exception &p) { cerr << p.what() << endl; } }

2 2

contribution to GiNaC IO "philosophy"
by Vaclav Smilauer 18 Jun '02

18 Jun '02

Hi folks. I sketched some very basic stuff around GiNaC::ex output. It could eventually handle all printing, uniformly and FROM ONE PLACE in the source. I am very interested in your comments on it as it serves nothing else; it is not useful yet. Some issues are addressed in the source. It is heavily commented and easy to understand. Have a look at it: http://www.volny.cz/smilauer/ginac_o.cc. Regards. Vaclav Smilauer

1 0

GiNaC 1.0.9 now available (AKA Episode I - The Indexed Menace)
by Christian Bauer 11 Jun '02

11 Jun '02

FADE IN EXT. UNIVERSITY BUILDING - EVENING It is a quiet, hot summer evening. The setting sun casts its last rays on the Physics Department building, giving the stone walls a wonderful warm golden glow. The only sounds that are heard are the raspy cries of a black swarm of ravens that circles in the sky. Two cyclists ride down the street in front of the building. CUT TO INT. UNIVERSITY BUILDING, OFFICE - CONTINUOUS There are numerous desks and computers in this small, dimly lit room in the fifth floor of the Physics Department building. The walls are lined with large cupboards, science fiction posters, GiNaC logo designs and hardcopies of 'Dilbert' cartoons. Quiet piano music fills the air. Only two people are still working at this time of day. One, RICHY K. is sitting in a corner of the room, close to the window, with his bare feet laid on top of the desk and a notebook computer in his lap. The other, CHRISTIAN B., is busy studying eBay article listings on one of two monitors on his desk in the middle of the room. RICHY K. presses a few keys on his notebook and takes a sip from a cocktail glass. Then he speaks without turning his eyes away from the screen. RICHY K. There's a tarball at the usual place now. CHRISTIAN B. Cool... CHRISTIAN B. clicks on the 'shell' icon on his computer's desktop and starts typing commands. CHRISTIAN B. So we're going to release today? RICHY K. Yup. He brings up a Mozilla window displaying the Slashdot front page on his notebook. CHRISTIAN B. Did you put the champagne in the fridge? RICHY K. Pardon? CHRISTIAN B. (louder) Did you put the champagne in the fridge? RICHY K. We don't have any champagne. CHRISTIAN B. How can we release without champagne? RICHY K. Only drinking all the time... CHRISTIAN B. types some more commands. CHRISTIAN B. Is this 1.1.0? RICHY K. Nope, 1.0.9. CHRISTIAN B. Will we have champagne when we get to 1.1.0? RICHY K. Maybe... CHRISTIAN B. slams down the 'Return' key on his keyboard and leans back. Progress messages of a compiler run start scrolling down the screen. He returns his attention to the eBay listings on the second monitor. CHRISTIAN B. They're selling an eight-CPU Origin for 180,000 here... RICHY K. Cool. Tell Hubert to buy it. CHRISTIAN B. Where is Hubert, anyway? RICHY K. I don't know... RICHY K. takes another sip from his orange-red cocktail. CHRISTIAN B. glances over the compiler output but then looks back at his browser window and types in a URL. CHRISTIAN B. Did you get yesterday's User Friendly? RICHY K. What? CHRISTIAN B. (louder) Yesterday's User Friendly. Did you understand the punch line? RICHY K. Nope. CHRISTIAN B. What does that Russian sentence mean? RICHY K. Don't know. CHRISTIAN B. You ought to know. You've been in Russia. RICHY K. They all spoke English there. CHRISTIAN B. Oh. The compiler run is still in progress. CHRISTIAN B. grabs his coffee mug, slowly stands up, and walks over to the coffee machine. After filling the mug he returns to his place. CHRISTIAN B. You're already writing the announcement? RICHY K. It's your turn this time. CHRISTIAN B. No, it's not. I wrote the announcement for 1.0.8. RICHY K. No, you didn't. I did. It's your turn now. CHRISTIAN B. It's always 'my turn'. Why is it always my turn? RICHY K. It isn't. You're only trying to sneak out of having to write it. CHRISTIAN B. I'm not. He turns back to the monitors. Seeing that the compiler run has finished successfully, he continues to enter commands. CHRISTIAN B. RPM builds fine. I'll move it to the FTP server. RICHY K. Pardon? CHRISTIAN B. (louder) I will upload the RPM to the FTP server. RICHY K. Suit yourself... CHRISTIAN B. Did you tag the CVS? RICHY K. gasps with ostentation and starts pressing keys. RICHY K. Tagged. CHRISTIAN B. Nearly... CHRISTIAN B. still hacks away at his keyboard. RICHY K. Are you writing the announcement now? CHRISTIAN B. It's your turn. Besides, I can't write announcements without champagne. RICHY K. There should still be some wine in the cupboard. CHRISTIAN B. turns around to the cupboard behind him and opens the lower door. His face brightens up when he sees several bottles of red and white wine. CHRISTIAN B. (smiling) I'll write the announcement... FADE OUT

1 0

optimized C output
by Hugo LECLERC 09 Jun '02

09 Jun '02

Hello, I have developed a class to produce optimized C output. As example, symbol x ("x"), y ("y"), z ("z"); ex A = sin (x * y * z*z) + x * x * y * z; ex B = x*x*y*y*z; Optimized_ex_output aw; aw.add ("A", A); aw.add ("B", B); aw.write(cout); gives double tmp0 = z; double tmp1 = y; double tmp2 = x; double tmp_gcd9 = tmp2*tmp1; double tmp_gcd8 = tmp_gcd9*tmp0; double A = tmp2*tmp_gcd8+sin(tmp0*tmp_gcd8); double B = tmp_gcd9*tmp_gcd8; It produce "already" optmized code (factorization, gcd, less use of /). It seems that g++ can produce similar code but these optimizations are already done in the code and the code is faster to compile. Nevertheless, there are cases where the produced code make faster results than g++ -O2 -ffast-math -fexpensive-optimizations... As I don't know how CVS works, I send you the sources. If you think that It is pertinent I would be happy to see this class (with corrections if necessary) in the GiNaC code. PS: many many thanks for your library and your humor. It's great.. -- Hugo LECLERC Applied Mechanics Laborator UMR CNRS 6604 UFR Sciences et Techniques 24, chemin de l'Epitaphe 25000 BESANCON - FRANCE

1 0

Re: can't subs(lst) on a function
by Chris Dams 23 May '02

23 May '02

Hello Hugo, I know casting to an ex is a solution (would not call it ``the solution'' though: ``the solution'' is editing the source files and recompiling GiNaC). It is not natural that you can use the method subs(lst) to an expression but not to a function. So, unless it turns out to be some weird compiler error in my gcc-version, I would rather see this fixed in future GiNaC versions than condemning future generations to having to use this cast. Greetings, Chris

1 0

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