- GiNaC-devel - ginac.de

[PURRS-devel] Annoying warning again
by Roberto Bagnara 06 Aug '02

06 Aug '02

Dear all, there is a warning about an unused parameter due to line 84 in basic.h (GiNaC 1.0.10): virtual void destroy(bool call_parent) { } Seeing this warning over and over again makes developing with GiNaC a real pain. Therefore I suggest replacing the above line with the following: virtual void destroy(bool /* call_parent */) { } Thanks a lot. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it _______________________________________________ PURRS-devel mailing list PURRS-devel(a)cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/purrs-devel

2 1

PATCH AGAIN: remove_all() method added to the containers
by Roberto Bagnara 05 Aug '02

05 Aug '02

Hi there, I am reiterating the following request because of the obvious reasons of functionality and efficiency. Moreover, the issue of C++ ABI compatibility (which suggested not to apply the given patch) seems now to be completely pointless: GCC 2.95 is ABI-incompatible with GCC 3.0, which is ABI-incompatible with GCC 3.1, which will almost certainly be ABI-incompatible with GCC 3.3. Moreover, hasn't the time of GiNaC 1.1 come yet? All the best Roberto Dear all, of course there are several ways in the current version of GiNaC to erase all the elements from a GiNaC container. However, as far as I can tell, they are either obscure or inefficient or both (removing one element at a time is inefficient, assigning from an empty container is obscure and still measurably inefficient and so forth). Removing all the elements of a container is a very common operation and forcing users to resort to kludges is, I believe, not a very good idea. Moreover, not providing the right method for a common operation reduces the implementor's latitude for future choices (what if you would like to use a different representation for containers? What if this new representation is such that the user's kludges for erasing all the elements are seriously inefficient?) You don't want your users to ask you whether _today_ it is best to clear all the elements using the technique A or by the tecnique B, right? It is not by chance that all the STL containers have a clear() method. Enough for advocacy, please find below a patch adding a remove_all() method to the containers. I feel that the name "remove_all" fits well with the others. The patch allows `make check' to complete successfully and the documentation looks good. I have been careful to follow your coding style. Please let me know if I haven't been successful and I will submit a revised patch. All the best Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it diff -rcp GiNaC-1.0.3.orig/doc/tutorial/ginac.texi GiNaC-1.0.3/doc/tutorial/ginac.texi *** GiNaC-1.0.3.orig/doc/tutorial/ginac.texi Fri Dec 21 12:38:03 2001 --- GiNaC-1.0.3/doc/tutorial/ginac.texi Sat Jan 19 18:22:28 2002 *************** canonical form. *** 1193,1198 **** --- 1193,1199 ---- @cindex @code{prepend()} @cindex @code{remove_first()} @cindex @code{remove_last()} + @cindex @code{remove_all()} The GiNaC class @code{lst} serves for holding a @dfn{list} of arbitrary expressions. These are sometimes used to supply a variable number of *************** and @code{prepend()} methods: *** 1230,1242 **** // ... @end example ! Finally you can remove the first or last element of a list with @code{remove_first()} and @code{remove_last()}: @example // ... l.remove_first(); // l is now @{x, 2, y, x+y, 4*x@} l.remove_last(); // l is now @{x, 2, y, x+y@} @} @end example --- 1231,1251 ---- // ... @end example ! You can remove the first or last element of a list with @code{remove_first()} and @code{remove_last()}: @example // ... l.remove_first(); // l is now @{x, 2, y, x+y, 4*x@} l.remove_last(); // l is now @{x, 2, y, x+y@} + @end example + + Finally, you can remove all the elements of a list with + @code{remove_all()}: + + @example + // ... + l.remove_all(); // l is now empty @} @end example diff -rcp GiNaC-1.0.3.orig/ginac/container.pl GiNaC-1.0.3/ginac/container.pl *** GiNaC-1.0.3.orig/ginac/container.pl Wed Dec 19 11:54:04 2001 --- GiNaC-1.0.3/ginac/container.pl Sat Jan 19 18:19:14 2002 *************** protected: *** 250,255 **** --- 250,256 ---- public: virtual ${CONTAINER} & append(const ex & b); virtual ${CONTAINER} & remove_last(void); + virtual ${CONTAINER} & remove_all(void); ${PREPEND_INTERFACE} ${SORT_INTERFACE} protected: *************** ${CONTAINER} & ${CONTAINER}::remove_last *** 547,552 **** --- 548,560 ---- return *this; } + ${CONTAINER} & ${CONTAINER}::remove_all(void) + { + ensure_if_modifiable(); + seq.clear(); + return *this; + } + ${PREPEND_IMPLEMENTATION} ${SORT_IMPLEMENTATION} _______________________________________________ PURRS-devel mailing list PURRS-devel(a)cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/purrs-devel

2 1

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