Dear all, there is a bug somewhere in GiNaC whereby some non-redundant parentheses are not output. The problem is shown below by means of simple `ginsh' session, but it can be reproduced equally well with C++ code. $ ginsh ginsh - GiNaC Interactive Shell (GiNaC V1.0.4) __, _______ Copyright (C) 1999-2002 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions. <-------------' For details type `warranty;'. Type ?? for a list of help topics.
2*I^(1/3); 2*I^(1/3) (2*I)^(1/3); 2*I^(1/3) 2*(I^(1/3)); 2*I^(1/3)
If this is confirmed to be a bug, we would need to develop a fix or a workaround quite urgently. Thanks a lot 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
Hi, On Fri, 25 Jan 2002, Roberto Bagnara wrote:
there is a bug somewhere in GiNaC whereby some non-redundant parentheses are not output. The problem is shown below by means of simple `ginsh' session, but it can be reproduced equally well with C++ code.
$ ginsh ginsh - GiNaC Interactive Shell (GiNaC V1.0.4) __, _______ Copyright (C) 1999-2002 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions. <-------------' For details type `warranty;'.
Type ?? for a list of help topics.
2*I^(1/3); 2*I^(1/3) (2*I)^(1/3); 2*I^(1/3) 2*(I^(1/3)); 2*I^(1/3)
If this is confirmed to be a bug, we would need to develop a fix or a workaround quite urgently.
(2*I)^(1/3); 2*I^(1/3) print(%);
Indeed, it's a bug. Internally, these are differnt objects. It just seems to be their output, i.e. power::print(). Look at this: power, hash=0xbffff638, flags=0x3, nops=2 2i (numeric), hash=0x80000840, flags=0xf 1/3 (numeric), hash=0x80000020, flags=0xf Can you look into that method? Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
"Richard B. Kreckel" wrote:
Hi,
On Fri, 25 Jan 2002, Roberto Bagnara wrote:
there is a bug somewhere in GiNaC whereby some non-redundant parentheses are not output. The problem is shown below by means of simple `ginsh' session, but it can be reproduced equally well with C++ code.
$ ginsh ginsh - GiNaC Interactive Shell (GiNaC V1.0.4) __, _______ Copyright (C) 1999-2002 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions. <-------------' For details type `warranty;'.
Type ?? for a list of help topics.
2*I^(1/3); 2*I^(1/3) (2*I)^(1/3); 2*I^(1/3) 2*(I^(1/3)); 2*I^(1/3)
If this is confirmed to be a bug, we would need to develop a fix or a workaround quite urgently.
(2*I)^(1/3); 2*I^(1/3) print(%);
Indeed, it's a bug. Internally, these are differnt objects. It just seems to be their output, i.e. power::print(). Look at this: power, hash=0xbffff638, flags=0x3, nops=2 2i (numeric), hash=0x80000840, flags=0xf 1/3 (numeric), hash=0x80000020, flags=0xf
Can you look into that method?
I checked power::print(), but this looks fine. The problem is, I believe, in numeric::print(). A patch that solves the problem is attached: it passes `make check' and fixes also the related bug exemplified by the following excerpt from a ginsh session (1.0.4):
(-I)^e; (I)^e
What is your advice? Given that we cannot put up with that bugs, should we install the patched version on all our machines or should we wait for 1.0.5? Translation: do you plan to release 1.0.5 RSN? ;-) All the best Roberto P.S. Did my patch adding erase_all() to the containers find its way to the CVS branch? -- 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.4.orig/ginac/numeric.cpp GiNaC-1.0.4/ginac/numeric.cpp *** GiNaC-1.0.4.orig/ginac/numeric.cpp Thu Jan 24 22:40:11 2002 --- GiNaC-1.0.4/ginac/numeric.cpp Fri Jan 25 17:52:29 2002 *************** void numeric::print(const print_context *** 403,427 **** } else { if (cln::zerop(r)) { // case 2, imaginary: y*I or -y*I ! if ((precedence() <= level) && (i < 0)) { ! if (i == -1) { ! c.s << par_open+imag_sym+par_close; ! } else { c.s << par_open; print_real_number(c, i); ! c.s << mul_sym+imag_sym+par_close; ! } ! } else { ! if (i == 1) { ! c.s << imag_sym; ! } else { ! if (i == -1) { ! c.s << "-" << imag_sym; ! } else { ! print_real_number(c, i); ! c.s << mul_sym+imag_sym; ! } } } } else { // case 3, complex: x+y*I or x-y*I or -x+y*I or -x-y*I --- 403,421 ---- } else { if (cln::zerop(r)) { // case 2, imaginary: y*I or -y*I ! if (i == 1) ! c.s << imag_sym; ! else { ! if (precedence() <= level) c.s << par_open; + if (i == -1) + c.s << "-" << imag_sym; + else { print_real_number(c, i); ! c.s << mul_sym+imag_sym; } + if (precedence() <= level) + c.s << par_close; } } else { // case 3, complex: x+y*I or x-y*I or -x+y*I or -x-y*I
Hi, On Fri, 25 Jan 2002, Roberto Bagnara wrote:
A patch that solves the problem is attached: it passes `make check'
Ok, but there really isn't any output checking. Originally, there was. But then we dropped it because the low degree of predictablility in canonical ordering made it a burden to maintain. Now, that we have an input parser, I fancy an idea: We can randomly create all sorts of rational numbers with weird exponents, rational complex bases etc. and build an ex from it. This has then been run through the anonymous evaluator and we can print it into an ostringstream. Then we can apply .to_str() on it, and have the expression be parsed again and compared with the original. If there are remaining bugs in either the parser or (more likely) output, this should help shake them out. Having this in the default regression tests would guard us against future failures, which are not unlikely to happen, a point to be proven soon...
and fixes also the related bug exemplified by the following excerpt from a ginsh session (1.0.4):
(-I)^e; (I)^e
Applied, thanks. This one seems to have crept in in version 0.8.1. Point proven. :-)
What is your advice? Given that we cannot put up with that bugs, should we install the patched version on all our machines or should we wait for 1.0.5? Translation: do you plan to release 1.0.5 RSN? ;-)
Maybe next week. Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
On Sat, 26 Jan 2002, Richard B. Kreckel wrote:
Now, that we have an input parser, I fancy an idea: We can randomly create all sorts of rational numbers with weird exponents, rational complex bases etc. and build an ex from it. This has then been run through the
If you replace "random" by "pseudo-random", i.e. deterministic, then this sounds like a good idea. However I dislike a "make check" which passes with a probability of 95% and mysteriously fails in 5%. Alex -- Alexander Frink E-Mail: Alexander.Frink@Uni-Mainz.DE Institut fuer Physik Phone: +49-6131-3923391 Johannes-Gutenberg-Universitaet D-55099 Mainz, Germany
Hi, On Tue, 29 Jan 2002, Alexander Frink wrote:
On Sat, 26 Jan 2002, Richard B. Kreckel wrote:
Now, that we have an input parser, I fancy an idea: We can randomly create all sorts of rational numbers with weird exponents, rational complex bases etc. and build an ex from it. This has then been run through the
If you replace "random" by "pseudo-random", i.e. deterministic, then this sounds like a good idea.
While nitpicking: if you give us some real random number source it shouldn't make a difference. :-)
However I dislike a "make check" which passes with a probability of 95% and mysteriously fails in 5%.
Hmmmmm??? Why should it fail at all? The whole point about the default output and the input-parser (a.k.a. ginsh-input syntax) was to be mutually compatible. Saludos -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
participants (3)
-
Alexander Frink
-
Richard B. Kreckel
-
Roberto Bagnara