September 2002 - PURRS-devel

purrs/src Recurrence.defs.hh
by Roberto Bagnara 24 Sep '02

24 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: roberto(a)cs.unipr.it 2002-09-24 12:16:00 Added files: src : Recurrence.defs.hh Log message: This is the main object PURRS operates upon: a recurrence. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Recurrence.defs.hh.diff…

1 0

purrs/tests recurrences
by Tatiana Zolo 23 Sep '02

23 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-23 23:20:55 Modified files: tests : recurrences Log message: Added three recurrence relation of the first order with inhomogeneous term not polynomial or polynomial times exponential that we solve successfully. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/tests/recurrences.diff?cvsr…

1 0

purrs/src rr_solver.cc
by Tatiana Zolo 23 Sep '02

23 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-23 23:17:42 Modified files: src : rr_solver.cc Log message: Extended function `solve_constant_coeff_order_1()': now, with gosper's algorithm, we solve also recurrence relation of the first order with inhomogeneous term not polynomial or polynomial times exponential (but only under condition that the summand of the sum is an hypergeometric term). Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/rr_solver.cc.diff?cvsro…

1 0

purrs/src gosper.cc
by Tatiana Zolo 23 Sep '02

23 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-23 23:13:05 Modified files: src : gosper.cc Log message: The function `gosper()' returns false only if the summand is not an hypergeometric term. Added a comment. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/gosper.cc.diff?cvsroot=…

1 0

purrs/src rr_solver.cc
by Tatiana Zolo 23 Sep '02

23 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-23 20:04:58 Modified files: src : rr_solver.cc Log message: Reorganization of the main function `solve()' in order to accept recurrence relation with variable coefficients. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/rr_solver.cc.diff?cvsro…

1 0

[Fwd: Re: One last time: annoying warning]
by Roberto Bagnara 23 Sep '02

23 Sep '02

-------- Original Message -------- Subject: Re: One last time: annoying warning Date: Mon, 23 Sep 2002 17:26:27 +0200 From: Christian Bauer <cbauer(a)zino.physik.uni-mainz.de> Reply-To: ginac-devel(a)zino.physik.uni-mainz.de To: ginac-devel(a)zino.physik.uni-mainz.de References: <3D8E0293.8040109(a)cs.unipr.it> Hi! On Sun, Sep 22, 2002 at 07:49:07PM +0200, Roberto Bagnara wrote: > I was composing my fourth message about the the unused parameter > in line 84 in basic.h (GiNaC 1.0.11) And I'm now composing my third answer to that... > and about the trivial and 100% safe patch I have proposed to fix it. Short answer: There is nothing to 'fix' here. Long answer: See below. > Having discovered that I was not completely ignored during all this time, > I had a chance to erase a message you would not have liked. /me dons the asbestos suit > I would now like to discuss the issue on purely technical grounds. So do I. > The point is that we need to replace the following line (84) of basic.h > virtual void destroy(bool call_parent) { } > with the following > virtual void destroy(bool /* call_parent */) { } > > We cannot follow the advice of Christian Bauer (*) to tell the > compiler not to warn about unused parameters for the simple > reason that we find these warnings very useful in our > development work. Then write a script that filters out warnings coming from ginac/basic.h... > In contrast, I believe the patch I am repeatedly proposing: > > 1) complies with the C++ standard; > 2) does not cause problems with any the versions of all the C++ > compilers we know of; > 3) preserves the information about what the bool parameter is; > 4) is good both for users that run with warnings on and for those > switching them off. 5) Mutilates perfectly valid code in a feeble attempt to keep some nitpicking compiler's trap shut. 6) Doesn't make the code any more transparent. Rather the opposite. Unused parameters are to be expected when overloading functions. A compiler that issues a warning about this needs to be gagged. What is it 'warning' us about, anyway? That the parameter is dispensable and can be removed? That would make some sense if this was pure C code. But here, the parameter is needed. The compiler is just too stupid/ignorant to see that. There's absolutely *nothing* whatsoever wrong with that line of code. Your 'fix' only serves to outsmart your compiler's warning heuristics. The function still has one unused parameter. Why doesn't the compiler warn about that? Accepting your fix may open the flood gates to invite all kinds of nonsense. I mean, what's next? Somebody asking us to change variable names because he's using a brain-damaged compiler that spits out Mathematica-esque warnings like "Possible spelling error: identifier 'numy' is similar to existing identifier 'numx'."? There has to be a line drawn somewhere, and I draw it at the point where the only purpose of a patch is to avoid a (pointless) compiler warning. Don't get me wrong. I'll gladly replace "while (c = *s++)" with "while ((c = *s++) != 0)" anytime, because that also makes the code more comprehensible. But I despise stuff like commenting out variable names, 'UNUSED' macros etc. in code that is 100% OK, just to avoid compiler messages. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

purrs/src rr_solver.cc
by Tatiana Zolo 23 Sep '02

23 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-23 17:05:44 Modified files: src : rr_solver.cc Log message: Changed `check_polynomials_times_exponentials()' in the more general `not_all_vector_zero()'. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/rr_solver.cc.diff?cvsro…

1 0

purrs/src gosper.cc
by Tatiana Zolo 23 Sep '02

23 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-23 17:03:43 Modified files: src : gosper.cc Log message: Added an assertion. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/gosper.cc.diff?cvsroot=…

1 0

purrs/src simplify.cc
by Tatiana Zolo 22 Sep '02

22 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-22 23:00:01 Modified files: src : simplify.cc Log message: Improved `collect_base_exponent()' swapping the calls to the function `collect_same_base()' and `collect_same_exponents()'. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/simplify.cc.diff?cvsroo…

1 0

One last time: annoying warning
by Roberto Bagnara 22 Sep '02

22 Sep '02

Dear GiNaC developer, I was composing my fourth message about the the unused parameter in line 84 in basic.h (GiNaC 1.0.11) and about the trivial and 100% safe patch I have proposed to fix it. In another window I was creating a new CVS repository for GiNaC so that we could avoid patching your releases manually over and over again. I was lucky enough to have the inspiration to double check the archives of ginac-devel(a)ginac.de before hitting the "send" button. Having discovered that I was not completely ignored during all this time, I had a chance to erase a message you would not have liked. (I don't think replies to messages sent to ginac-devel should only be sent to the list, but anyway I have now subscribed it: from what I can see this entitles me to receive also some more spam). I would now like to discuss the issue on purely technical grounds. The point is that we need to replace the following line (84) of basic.h virtual void destroy(bool call_parent) { } with the following virtual void destroy(bool /* call_parent */) { } We cannot follow the advice of Christian Bauer (*) to tell the compiler not to warn about unused parameters for the simple reason that we find these warnings very useful in our development work. In contrast, I believe the patch I am repeatedly proposing: 1) complies with the C++ standard; 2) does not cause problems with any the versions of all the C++ compilers we know of; 3) preserves the information about what the bool parameter is; 4) is good both for users that run with warnings on and for those switching them off. I would be very grateful if someone could tell me what is so wrong with it that we have to set up a paraller CVS repository for GiNaC. Thanks a lot Roberto (*) "I suggest turning off that compiler warning. Yes, I'm serious." -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0