On Sat, 7 Apr 2001, Christian Bauer wrote:
The traverse() function needs further refinement because some classes have additional properties that are not accessible via op() (the most noticable error is that all functions are printed as "function(...)" instead of with their real name; and there doesn't seem to be a way to get the name from a function object (this will be corrected shortly)), but basically it seems to be what you want.
Thanks for the hint! I'll give it a try: this function is going to be lengthy but at least there is no need to change GiNaC for that. On Sat, 7 Apr 2001, Richard B. Kreckel wrote:
On Sat, 7 Apr 2001, Pearu Peterson wrote:
feel right. And on the other hand, you hardly want to support Python (or any other third party language) output formats.
Why not? Isn't this exactly what class print_context and decendants are supposed to be good for provided we get the right patches for inclusion into the GiNaC::*::print() methods?
Right, but I doubt that it will hold for the Python interface (pyGiNaC) that I am working on, because 1) Python output format is useful **only** if one is actually going to use pyGiNaC, not just Python. 2) pyGiNaC unfortunately depends on Boost.Python (www.boost.org, which greatly simplifies wrapping C++ classes to Python) and therefore I cannot expect that you want to include all this stuff to GiNaC. Thanks for you replies, Pearu