September 2002 - PURRS-devel

purrs/src Expr.defs.hh Expr.inlines.hh Number. ...
by Tatiana Zolo 28 Sep '02

28 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-28 19:56:13 Modified files: src : Expr.defs.hh Expr.inlines.hh Number.defs.hh Number.inlines.hh Log message: Removed useless functions. Added assertion in `ex_to_number()'. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Expr.defs.hh.diff?cvsro… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Expr.inlines.hh.diff?cv… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Number.defs.hh.diff?cvs… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Number.inlines.hh.diff?…

1 0

Re: One last time: annoying warning
by Gabriel Dos Reis 28 Sep '02

28 Sep '02

Roberto Bagnara <bagnara(a)cs.unipr.it> writes: | Gabriel Dos Reis wrote: | > Roberto Bagnara <bagnara(a)cs.unipr.it> writes: | > | > [...] | > | > | What is important is that the GCC people taking care of the standard | > | library do the right thing. Since they know that someone may very | > | legitimately wish to compile with, e.g., -W -Wall, they write code | > | like | > | | > | virtual iter_type | > | do_get_time(iter_type __s, iter_type /*__end*/, ios_base&, | > | ios_base::iostate& /*__err*/, tm* /*__t*/) const | > | { return __s; } | > | > I'm one of those GCC people taking care of the library and I can | > assure you I don't particularly appreciate that style (like some other | > things in the V3 STYLE). So, I would say that you should be very | > careful in drawing conclusions from things you might read in the V3 | > source code -- not every one has the same idea of the styles to be used. | | It is not a matter of style: it is a matter of respect for the users. I guess it depends on what you define to be irrespectful for users. Given the tone you're taking and the lack of recognizing actual facst, I guess there is no much interest in continuing this thread. [...] | Huh? Looks like a copy-and-paste error... No. Just go and check out. -- Gaby

2 1

Re: One last time: annoying warning
by Gabriel Dos Reis 27 Sep '02

27 Sep '02

Roberto Bagnara <bagnara(a)cs.unipr.it> writes: [...] | What is important is that the GCC people taking care of the standard | library do the right thing. Since they know that someone may very | legitimately wish to compile with, e.g., -W -Wall, they write code | like | | virtual iter_type | do_get_time(iter_type __s, iter_type /*__end*/, ios_base&, | ios_base::iostate& /*__err*/, tm* /*__t*/) const | { return __s; } I'm one of those GCC people taking care of the library and I can assure you I don't particularly appreciate that style (like some other things in the V3 STYLE). So, I would say that you should be very careful in drawing conclusions from things you might read in the V3 source code -- not every one has the same idea of the styles to be used. [...] | (stl_alloc.h, lines 120 ff.), ..., you will find hundreds of examples | like that. Naturally, I am really thankful they do that. Naturally you'll also see the opposite: >From stl_algobase.h: template<typename _InputIter, typename _OutputIter> inline _OutputIter __copy(_InputIter __first, _InputIter __last, _OutputIter __result, input_iterator_tag) template<typename _InputIter, typename _OutputIter> inline _OutputIter __copy(_InputIter __first, _InputIter __last, _OutputIter __result, input_iterator_tag) and so one. -- Gaby

2 1

purrs/src Constant.defs.hh Expr.defs.hh Matrix ...
by Tatiana Zolo 27 Sep '02

27 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-27 20:08:12 Modified files: src : Constant.defs.hh Expr.defs.hh Matrix.cc Number.cc Number.defs.hh Number.inlines.hh gosper.cc Log message: Moved methods from Number.cc to Number.inlines.hh. Added some comments. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Constant.defs.hh.diff?c… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Expr.defs.hh.diff?cvsro… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Matrix.cc.diff?cvsroot=… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Number.cc.diff?cvsroot=… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Number.defs.hh.diff?cvs… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Number.inlines.hh.diff?… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/gosper.cc.diff?cvsroot=…

1 0

purrs/src Expr.defs.hh Expr.inlines.hh globals ...
by Tatiana Zolo 27 Sep '02

27 Sep '02

CVSROOT: /cvs/purrs Module name: purrs Changes by: zolo(a)cs.unipr.it 2002-09-27 19:18:05 Modified files: src : Expr.defs.hh Expr.inlines.hh globals.cc simplify.cc Log message: Added the binary operators Expr with Expr. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Expr.defs.hh.diff?cvsro… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/Expr.inlines.hh.diff?cv… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/globals.cc.diff?cvsroot… http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/simplify.cc.diff?cvsroo…

1 0

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

27 Sep '02

-------- Original Message -------- Subject: Re: One last time: annoying warning Date: Fri, 27 Sep 2002 18:17:54 +0200 (CEST) From: Richard B. Kreckel <kreckel(a)zino.physik.uni-mainz.de> Reply-To: ginac-devel(a)zino.physik.uni-mainz.de To: GiNaC developers list <ginac-devel(a)zino.physik.uni-mainz.de> Hi again, On Thu, 26 Sep 2002, Roberto Bagnara wrote: [...] > You are violating [17.4.3.1.2], for instance. LOL! I was actually anticipating this to come up. Anything else, Sir? [...] > a) writing header files so as to suit the needs of as many users > as possible, and Exactly. If those leading underscores pose a problem in any realistic compilation environment I will happily patch it. Until then there is nothing to worry about. > b) ask for and provide clearly specified interfaces Good. So let me next specify `lsolve()' and it's relation to the matrix class. Just some thoughts: that whole notion of "clearly specified interfaces" is not always entirely clear. As soon as one allows general expressions lie `x+sin(x)+cos(2*x)' one opens a pandora's box of controversial evaluations, both anonymous and named ones. It is not always easy to clearly specify the intent since that appears clearly as people work with the system and not earlier. Remember that `sqrfree()' discussion and the change in behaviour between GiNaC-1.0.0 and GiNaC-1.0.1? As a developer, I find a set of regression tests more useful than a set of formal specifications since a problem is much easier trapped there. I hope you do the same. However: what is unclear about the notion of polynomials? Regards -richy. -- Richard B. Kreckel <Richard.Kreckel(a)GiNaC.DE> <http://www.ginac.de/~kreckel/> -- 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 demos/purrs_eqs_cgi.cc demos/purrs_rrs_c ...
by Tatiana Zolo 27 Sep '02

27 Sep '02

1 0

purrs demos/purrs_eqs_cgi.cc demos/purrs_rrs_c ...
by Tatiana Zolo 27 Sep '02

27 Sep '02

1 0

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

26 Sep '02

Christian Bauer wrote: >>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. "Mutilates"?! Putting the argument name within comments "mutilates"? Come on! > 6) Doesn't make the code any more transparent. Rather the opposite. It makes clear that the argument is _intentionally_ unused. Pretty obvious in the specific case, but, more generally, not using function arguments may happen (and does happen) also by mistake. > Unused parameters are to be expected when overloading functions. So what? > What is it 'warning' us > about, anyway? That the parameter is dispensable and can be removed? No: that the parameter is not being used in the function body. This catches a significant number of mistakes. Many people use g++ and compile with -Wall and they agree that it is a nice thing to be warned about that cases. > There's absolutely *nothing* whatsoever wrong with that line of code. Strictly speaking, the line is not wrong but only significantly less useful than it could be. It only serves well the portion of your user base not using g++ or its extra-warnings options. It does not serve well others. > Your > 'fix' only serves to outsmart your compiler's warning heuristics. It is not a heuristics in the usual sense: unused arguments are always flagged when these warnings are enabled. And this is so by design. The same functionality is available in other C++ compilers. Guess why. > The function > still has one unused parameter. Why doesn't the compiler warn about that? Because omitting the argument name is the ISO standard compliant way of specifying that the argument is _intentionally_ unused. While omitting the argument altogether causes an information loss, omitting it by commenting it out is perfectly OK. > [...] keep some nitpicking compiler's trap shut [...] > A compiler that issues a warning about this needs to be gagged. [...] > The compiler is just too stupid/ignorant to see that. [...] > Your 'fix' only serves to outsmart your compiler's warning heuristics. [...] > Accepting your fix may open the flood gates to invite all kinds of nonsense. > [...] I despise stuff like commenting out variable names [...] You have a very simple way to satisfy the entire user base and, in particular, those of us compiling with extra warnings enabled. Instead you are choosing to disrespect users and contributors of GiNaC (and the GCC authors as an extra bonus) by imposing your religious arguments upon them. This is a serious mistake for anyone and for a library provider is even worse. Anyway, starting from now, the PURRS project will reduce its dependence on GiNaC as much as possible. At the same time we will create a parallel CVS repository for GiNaC + our improvements (you know, those idiotic things we like and you despise). Good luck 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

2 4

Re: One last time: annoying warning
by Gabriel Dos Reis 26 Sep '02

26 Sep '02

"Richard B. Kreckel" <kreckel(a)zino.physik.uni-mainz.de> writes: [...] | I would bet that the GCC developers would agree with him on this | particular unused parameter issue -- but this is speculative. It depends on the GCC developer :-) *I* certainly agree with him; but I can only speak for myself. -- Gaby

1 0