GiNaC/ginac print.h ...

[Pearu Peterson]

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