Francesco Biscani wrote:
I'm using ginac 1.3.4 and trying to transform from std::string to ex. I'm using the small test program present in the FAQ:
--------------------------------------------------------- #include <iostream> #include <string> #include <stdexcept> #include <ginac/ginac.h> using namespace std; using namespace GiNaC;
int main() { symbol x("x"); string s;
cout << "Enter an expression containing 'x': "; getline(cin, s);
try { ex e(s, lst(x)); cout << "The derivative of " << e << " with respect to x is "; cout << e.diff(x) << ".\n"; } catch (exception &p) { cerr << p.what() << endl; } } ---------------------------------------------------------
The problem is that it does not work at all. Example output:
Enter an expression containing 'x': 5+x The derivative of x with respect to x is 1
I.e., "5+x" is parsed simply as x. With different expressions I get other wierd errors, like:
Enter an expression containing 'x': 5+3*x^2 The derivative of 2 with respect to x is 0.
syntax error, unexpected T_EOF, expecting ']' or ',' at
As strange as it sounds, ginsh seems not to have these problems
Type ?? for a list of help topics.
diff(x^2+sin(x),x);
2*x+cos(x)
I'm using gcc 4.1.1 on Gentoo. ginac was compiled with "-O2" c(xx)flag.
Thanks very much for ginac! I'm writing an algebraic manipulator software for Poisson series (celestial mechanics), and ginac would really help me manipulate the series' coefficients (instead of writing some ad-hoc representation for them). I hope this issue can be resolved.
I'm unable to reproduce your problem using either Debian/testing (gcc 4.1.2-prerelease) or Debian/stable (gcc 3.3.5). Over here, it works as expected. I'm CCing ginac-list, maybe someone there has a similar system and can reproduce your problem? The behavior you describe sounds too weird to be true. I recommend first using another system or compiler version in order to get a clue where it is coming from. Luck -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi, Richard B. Kreckel schrieb:
I'm unable to reproduce your problem using either Debian/testing (gcc 4.1.2-prerelease) or Debian/stable (gcc 3.3.5). Over here, it works as expected. I'm CCing ginac-list, maybe someone there has a similar system and can reproduce your problem?
The behavior you describe sounds too weird to be true. I recommend first using another system or compiler version in order to get a clue where it is coming from.
i have the same problems on SuSE 9.3 with gcc 4.1.1. It's probably the compiler that causes these problems (3.x, 4.0.3 are fine). I am going to try the SVN version now. Regards, Jens
Hello, On Sun, Jul 09, 2006 at 09:30:33PM +0200, Richard B. Kreckel wrote:
I'm unable to reproduce your problem using either Debian/testing (gcc 4.1.2-prerelease) or Debian/stable (gcc 3.3.5). Over here, it works as expected. I'm CCing ginac-list, maybe someone there has a similar system and can reproduce your problem?
The behavior you describe sounds too weird to be true. I recommend first using another system or compiler version in order to get a clue where it is coming from.
check/exams fails due to parser errors on my Debian/unstable system (g++-4.1 *Debian version* 4.1.1-7). The error is somewhere in exam_numeric.cpp:exam_numeric6(), here is a backtrace: Catchpoint 11 (exception thrown) 0x20fe54d5 in __cxa_throw () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x20fe54d5 in __cxa_throw () from /usr/lib/libstdc++.so.6 #1 0x20c13fb5 in GiNaC::ex::construct_from_string_and_lst (s=@0x58dada3c, l=@0x58dada94) at /home/pc7135/varg/src/ginac-1.3.4/ginac/ex.cpp:538 #2 0x08060182 in exam_numeric6 () at /home/pc7135/varg/src/ginac-1.3.4/check/../ginac/ex.h:357 #3 0x08067ad9 in exam_numeric () at /home/pc7135/varg/src/ginac-1.3.4/check/exam_numeric.cpp:388 #4 0x0817cf3f in main () at /home/pc7135/varg/src/ginac-1.3.4/check/exams.cpp:40 (gdb) frame 1 (gdb) print s $5 = (const string &) @0x58dada3c: {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x81d60cc "0^(I*sym)"}} (gdb) call l.dbgprint() {sym} BTW, we have discussed similar problem with ginac 1.4 tests some time ago (see http://www.ginac.de/pipermail/ginac-list/2006-May/000835.html) You have (almost) convinced me of the compiler bug... Best regards, Alexei -- All science is either physics or stamp collecting.
Hi, Sheplyakov Alexei schrieb:
BTW, we have discussed similar problem with ginac 1.4 tests some time ago (see http://www.ginac.de/pipermail/ginac-list/2006-May/000835.html) You have (almost) convinced me of the compiler bug...
the latest SVN gcc also breaks. Disabling optimization when compiling GiNaC makes the bug vanish (no matter what version). But the interesting news is: I compiled bison version 2.3 and used it for the compilation of GiNaC. That removes the bug also! Before I used the installed bison version 1.85. So my guess is, that bison has some issues with the new gcc 4.1. Can anybody reproduce my findings? Regards, Jens
Hello, On Mon, Jul 10, 2006 at 02:39:57PM +0200, Jens Vollinga wrote:
But the interesting news is: I compiled bison version 2.3 and used it for the compilation of GiNaC. That removes the bug also! Before I used the installed bison version 1.85.
So my guess is, that bison has some issues with the new gcc 4.1. Can anybody reproduce my findings?
Yes. Re-generating input_parser.{cc,h} with bison 2.3 (default version on my system) makes the error vanish. Best regards, Alexei. -- All science is either physics or stamp collecting.
Jens Vollinga wrote:
Sheplyakov Alexei schrieb:
BTW, we have discussed similar problem with ginac 1.4 tests some time ago (see http://www.ginac.de/pipermail/ginac-list/2006-May/000835.html) You have (almost) convinced me of the compiler bug...
the latest SVN gcc also breaks. Disabling optimization when compiling GiNaC makes the bug vanish (no matter what version).
But the interesting news is: I compiled bison version 2.3 and used it for the compilation of GiNaC. That removes the bug also! Before I used the installed bison version 1.85.
Excellent!
So my guess is, that bison has some issues with the new gcc 4.1. Can anybody reproduce my findings?
@Hans: are these known issues? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (3)
-
Jens Vollinga
-
Richard B. Kreckel
-
varg@theor.jinr.ru