On Tue, 2005-01-11 at 21:24 +0200, Matti Peltomäki wrote:
Hi,
I wanted to check out the use of lsolve() inspired by check/exam_lsolve.cpp See also bin/check_lsolve.py in the PyGiNaC source tree. It's basically a straight pythonization of the C++ code.
Yes. Thanks for the pointer.
Below is a short example showing what I did and which errors I got. I run python as './run python2.3' in the root of pyginac source tree after having succesfully built it with scons. I've got basically (exactly?) the same configuration as you, but I get this result instead:
So do I now. The problem turned out be my fault. I had upgraded GiNaC from 1.2.4 to 1.3.0 in the process of compiling PyGiNaC (after realising that it was indeed needed) with the result that objects built against the earlier version were left around. Without doing the same mistake again, I cannot reproduce the odd behaviour anymore.
I'll add a check for this that gets run at import time. For the GiNaC folks: Is there any guarantee that the values for the tinfo constants will not change between tiny versions of GiNaC? Phrased differently: are the tinfo constants considered part of the external ABI? Thanks, -Jonathan Brandmeyer