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…
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…
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=…
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…
-------- 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
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
