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
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.
Indeed, it's a bug. Internally, these are differnt objects. It just seems to be their output, i.e. power::print(). Look at this:
(2*I)^(1/3);
2*I^(1/3)
print(%);
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" 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.
Indeed, it's a bug. Internally, these are differnt objects. It just seems to be their output, i.e. power::print(). Look at this:
(2*I)^(1/3);
2*I^(1/3)
print(%);
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?
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 bugexemplified 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.
participants (2)
-
Richard B. Kreckel -
Roberto Bagnara