Python bindings to GiNaC
Hello all, I wrote new Python bindings to ginac, because PyGiNaC (http://cens.ioc.ee/projects/pyginac/) seems to be dead and I wasn't able to even compile it. Currently I only support classes: basic, symbol, numeric, ex. But more can be done quite easily, unfortunately I probably won't have time to continue on it. More info at: http://ondrej.certik.cz/pyginac.php Does anyone of you would like to use ginac in python, or does everybody use c++/cint? Yours, Ondrej Certik
On Mon, 2005-01-03 at 14:53 +0100, Ondrej Certik wrote:
Hello all, I wrote new Python bindings to ginac, because PyGiNaC (http://cens.ioc.ee/projects/pyginac/) seems to be dead and I wasn't able to even compile it.
Currently I only support classes: basic, symbol, numeric, ex. But more can be done quite easily, unfortunately I probably won't have time to continue on it. More info at:
http://ondrej.certik.cz/pyginac.php
Does anyone of you would like to use ginac in python, or does everybody use c++/cint?
Yours, Ondrej Certik
So have I, and I have support for a larger number of classes including matrix, numeric, relational, power, add, mul, constant, function, integral and others. GiNaC::lst is automatically converted to a Python list. See www.sourceforge.net/projects/pyginac/. I have not produced a release yet since I have not ported the documentation over, but CVS is current and usable. Would you like to collaborate with me on this? Personally, I prefer to use a mixed C++/Python environment, leaning on Python as an alternative to cint and ginsh rather than an alternative to C++. The approach that I took which is different from the prior efforts is that I always unwrap the child of an ex to its actual class. I did this because I think Python's dynamic object system is easier to use in Python than using ex's dynamic object system would be from Python (this isn't a complaint against it from the C++ side). For example, to see if you have an add object in hand, you test foo.__class__ == add, or use the builtin function isinstance( foo, add). -Jonathan
Hi, On Tue, 4 Jan 2005, Jonathan Brandmeyer wrote:
So have I, and I have support for a larger number of classes including
I find this project of your pretty interesting. I played around with it a little bit (was able to build it just fine etc.). However, I stumbled into a problem. I wanted to check out the use of lsolve() inspired by check/exam_lsolve.cpp in GiNaC source tree. Namely, I try to solve 3*x+5==8 for x. Since both the equation and the answer are instances of relational, one has to access the rhs and lhs to extract the answer. Now, it seems that if another side of a relational is numeric, unwrap_ex() does not seem to be able to unwrap it properly, throwing the exception "Could not unwrap an ex of unknown type." This seems strange since unwrap_ex() throws this exception if the tinfo of the object does not match any one listed in ex.cpp (and TINFO_numeric is listed). This does not happen, if the numeric is a term in an add, for instance. Is this something that I do wrong or what is going on in the relational? 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. Python 2.3.4 (#2, Dec 3 2004, 13:53:17) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
from ginac import *; x = symbol("x"); eq = ( 3*x + 5 == 8); eq.rhs[1] <cginac.numeric object at 0xb7dda4f4> print(eq.rhs[1]) 5 eq.lhs Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: Could not unwrap an ex of unknown type. answer = lsolve([eq], [x]) answer [<cginac.relational object at 0xb7e43e3c>] answer[0].rhs <cginac.symbol object at 0xb7e3d8cc> print(answer[0].rhs) x answer[0].lhs Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: Could not unwrap an ex of unknown type.
Best regards, Matti -- Matti Peltomaki, Undergraduate Research Assistant Laboratory of Physics Helsinki University of Technology
On Sun, 2005-01-09 at 20:45 +0200, Matti Peltomäki wrote:
Hi,
On Tue, 4 Jan 2005, Jonathan Brandmeyer wrote:
So have I, and I have support for a larger number of classes including
I find this project of your pretty interesting. I played around with it a little bit (was able to build it just fine etc.). However, I stumbled into a problem.
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.
in GiNaC source tree. Namely, I try to solve 3*x+5==8 for x. Since both the equation and the answer are instances of relational, one has to access the rhs and lhs to extract the answer. Now, it seems that if another side of a relational is numeric, unwrap_ex() does not seem to be able to unwrap it properly, throwing the exception "Could not unwrap an ex of unknown type." This seems strange since unwrap_ex() throws this exception if the tinfo of the object does not match any one listed in ex.cpp (and TINFO_numeric is listed). This does not happen, if the numeric is a term in an add, for instance.
Is this something that I do wrong or what is going on in the relational?
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: Python 2.3.4 (#2, Dec 3 2004, 13:53:17) [GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
from ginac import * x = symbol('x') eq = 3*x+5 == 8 eq.lhs <cginac.add object at 0xb7e34dec> eq.rhs <cginac.numeric object at 0xb7de5614> answer = lsolve([eq], [x]) print answer [<cginac.relational object at 0xb7e39f2c>] print [str(x) for x in answer] ['x==1'] print answer[0].lhs x print answer[0].rhs 1
from ginac import *; x = symbol("x"); eq = ( 3*x + 5 == 8); eq.rhs[1] <cginac.numeric object at 0xb7dda4f4> print(eq.rhs[1]) 5
This is really weird. The only way you should be able to get this is if eq was defined to be 8 == 3*x + 5. What is the value of ginac.version?
eq.lhs Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: Could not unwrap an ex of unknown type. answer = lsolve([eq], [x]) answer [<cginac.relational object at 0xb7e43e3c>] answer[0].rhs <cginac.symbol object at 0xb7e3d8cc> print(answer[0].rhs) x answer[0].lhs Traceback (most recent call last): File "<stdin>", line 1, in ? RuntimeError: Could not unwrap an ex of unknown type.
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. Thanks for the help. I would most probably have been looking in the wrong direction without it. Regards, Matti -- Matti Peltomaki, Undergraduate Research Assistant Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B
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
Hi! On Tue, Jan 11, 2005 at 09:42:07PM -0500, Jonathan Brandmeyer wrote:
Phrased differently: are the tinfo constants considered part of the external ABI?
Yes, they are (because of the is_exactly_a<>() inline functions). Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/
On Tue, 2005-01-11 at 21:24 +0200, Matti Peltomäki wrote:
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)
Can you be more specific about this need? PyGiNaC is supposed to be buildable against GiNaC 1.2.x. Thanks, -Jonathan Brandmeyer
Hi,
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) Can you be more specific about this need? PyGiNaC is supposed to be buildable against GiNaC 1.2.x.
Sorry for the late reply but yes, I can. Trying to build against GiNaC 1.2.4, I get the following error during compilation. scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... g++ -pipe -march=pentium3 -g -Wall -W -Wsign-compare -Wconversion -std=c++98 -Wdisabled-optimization -pedantic -Wno-unused-parameter -fPIC -DPYGINAC_AVOID_EX -Iinclude -I/usr/include/python2.3 -I/usr/local/include -c -o src/basic.os src/basic.cpp src/basic.cpp: In function `void pyginac::wrap_basic()': src/basic.cpp:420: error: `eval_integ' is not a member of type `GiNaC::basic' scons: *** [src/basic.os] Error 1 scons: building terminated because of errors. If I recall correctly, eval_integ was introduced in 1.3.0 (the basic symbolic integration stuff). Regards, Matti -- Matti Peltomaki, Undergraduate Research Assistant Laboratory of Physics Helsinki University of Technology 040 7576977, room Y308B
participants (4)
-
Christian Bauer
-
Jonathan Brandmeyer
-
Matti Peltomäki
-
Ondrej Certik