October 2005 - GiNaC-devel

Breaking News
by Richard B. Kreckel 07 Oct '05

07 Oct '05

Erlangen, October 6, 2005 (for immediate release) The GiNaC/CLN hackers, the leading providers of advanced mathematical software solutions for research and industrial applications, are proud to announce that their system scored second in the "Many Digits" Friendly Competition [0], held 3rd and 4th October at the Radboud University in Nijmegen, The Netherlands. Although Richard Kreckel, former vice president of GiNaC's PR department has retired into industry, he was available to compete against the world's finest exact real arithmetic hackers. "It was a thrilling experience" said Richard Kreckel at a meeting with press. "I basically started hacking on the competition problems Monday morning and stopped only an hour before our turn at the competition Tuesday afternoon. Little sleep compensated only by beer, coffee and lots of caffeinated peppermints. It was quite similar to those release parties at University." Maybe it wasn't enough caffeine, though. The winner at the competition was the MPFR team headed by Paul Zimmermann. Says Richard Kreckel: "Well, they certainly cut some corners. They discovered, coded and tested closed-form solutions for hard iterative problems, thus being better than anybody else by orders of magnitude. Their winning is well-deserved. Congratulations!" Other competing systems were iRRAM, Wolfram's Mathematica, Maple, RealLib, COMP, Few Digits and Bignum. Although only provisional rankings have been published so far [1], ground-shaking changes in the results are not expected. The "Many Digits" Friendly Competition was of purely numerical nature: none of the 24 competition problems called for symbolic manipulations. Hence, it really was a measure of CLN's numerical power, rather than GiNaC's symbolic flexibility. Bruno Haible, the original author of the CLN library could not be reached for a statement. It is assumed that he is busy hunting down bugs in several dozen GNU software packages at the same time. He has all the time. After all, he has retired to industry, too. [0] <http://www.cs.ru.nl/~milad/manydigits/> [1] <http://www.cs.ru.nl/~milad/manydigits/raw_provisional.html>

1 0

Newest version of my patch.
by Chris Dams 06 Oct '05

06 Oct '05

Hi! I found another error. In the constructor of safe_inserter "bool dodummies" should be "dodummies" in order to use the member variable instead of creating a local one. The newest version is attached. Best, Chris

1 0

Newest version of my patches
by Chris Dams 05 Oct '05

05 Oct '05

Dear all, I discovered that in my patch there was is_a<whatever> that should have been an is_exactly_a<whatever>, so here's a new patch. Besides that, it contains all changes that I sent recently. Best wishes, Chris

1 0

Substituting and dummy indices.
by Chris Dams 04 Oct '05

04 Oct '05

Dear GiNaCers, Substitution and dummy index renaming also seem to have some problems getting along with each others. Here's a patch that seems to solve it and also includes the changes I mailed last evening ("Another patch"). Best wishes, Chris

1 0

Another patch
by Chris Dams 03 Oct '05

03 Oct '05

Dear all, The idea of renaming dummy indices when expressions are raised to a power or when this is necessary in the case of a subsitution, is a great idea. However, it seems rather inconsistently implemented. E.g., if you calculate x^2 as power(x,2) then dummy indices are renamed but not if you do it like x*x. The attached patch makes renaming work if multiplications are constructed using operator* or by the mul::mul (exvector) constructor. Furthermore, the function rename_dummy_indices_uniquely was not aware of the existence of spinidx. The patch also corrects this. Best wishes, Chris

1 0

Speeding up simplify_indexed(): 2nd try
by Chris Dams 03 Oct '05

03 Oct '05

Dear all, Here is a new attempt at the patch. The problem with the previous one was that if one symmetrizes only amongst indices of precisely the same type, also renaming of indices should be done taking these types into account. Another advantage of this is that if a user uses for instance mu and nu for indices with a variance, these will no longer end up being used as indices without variance. I think this makes output more readable. Best, Chris

1 0