ANNOUNCE: PySymbolic - Doing Symbolics in Python
Alex Martelli
aleaxit at yahoo.com
Wed Oct 11 09:09:27 EDT 2000
More information about the Python-list mailing list
Wed Oct 11 09:09:27 EDT 2000
- Previous message (by thread): ANNOUNCE: PySymbolic - Doing Symbolics in Python
- Next message (by thread): ANNOUNCE: PySymbolic - Doing Symbolics in Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
"Janko Hauser" <jhauser at ifm.uni-kiel.de> wrote in message news:87og0r39n5.fsf at ifm.uni-kiel.de... > Perhaps I'm wrong, but I understood that GiNaC does not directly > expose an API, but helps a C++ programmer to write expressions > directly in C++, which would mean that the interface itself needs to > be written and beforehand defined in C++. So SWIG would not be an > option, perhaps CXX or something like that. Another system to look at > is YACAS, which has an API. My impression is that YACAS, like a typical CAS system, implements and exposes its own little scripting language, while GiNaC's novelty is that it *doesn't* -- it _just_ implements and exposes the functionality at the low (i.e., C++) level. So, if one's purpose is basically to use it as an engine from _another_ scripting language (namely, Python:-), one should be able to avoid having to "work around" the intrinsic scripting language, &c. As I said, it's an _impression_ -- I haven't made any in-depth study... SWIG, in theory, should be usable to interface Python (and other scripting languages it supports) to C++ code just as well as to C code. CXX and py_cpp are, clearly, also feasible alternatives. Alex
- Previous message (by thread): ANNOUNCE: PySymbolic - Doing Symbolics in Python
- Next message (by thread): ANNOUNCE: PySymbolic - Doing Symbolics in Python
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list