[GiNaC-devel] AsyForGiNaC - an output extension producing Asymptote files

[Jens Vollinga]

Dear Daniel,

Daniel Seidel schrieb:
> I agree with you that it is a good idea for the existing output formats,
> because it's really better if the mathematical expression remains, than
> printing something like [GiNaC-Object] and I have no doubts about this
> being a good solution.
> But, concerning the output for asymptote it will be different. Because
> usually it should not print only the formula, it should print the
> description of a graph. So at the end (after processing the output file
> with Asymptote there should be a picture. The text produced from
> asy_print is far more then the formula. It is code for Asymptote, which
> describes how to draw. This produced output doesn't even necessarily
> have to include the literally written formula, that would be produced
> from all other print_context. So the code would not be useful at all.

you're probably right on this. But now just one question comes to my 
mind: if this Asymptote output is such complex, isn't the output of one 
object really independent of all the other? If you have something like 
x+y (don't take it literally, it is really much too simple an example) 
and the output method for x produces lengthy Asymptote commands, and 
after this the output method for y does produce equally lengthy 
commands, and finally 'add' does the same (how actually?), couldn't it 
be that these three outputs somehow interfere destructively?? Like x is 
plotting the coordinate system there, but y wants it somewhere else ...

This question has not much to do with our ongoing discussion, I just ask 
out of curiosity.

>> If after some long calculation somebody's program starts to print its 
>> (often comparatively small) result and just "crashes" with an exception, 
>> lots of somebodies would probably be very annoyed. They could file a bug 
>> report and wait until somebody fixes the source code (the advanced user 
>> may correct the bug(?) for himself, of course). But the aforementioned 
>> option to correct the buggy output in some text editor is not possible. 
>> Essentially they would have to (wait for help and then to) run their 
>> program again.
> why should it crash more often? (just because I don't understand this)

Not more often. The difference is: programs terminate normally with full 
output vs. programs terminate abnormally at some point without full 
output. Exceptions, if not caught, look very much like ordinary program 
crashes for the user.

> I doubt that this is a good idea, not only because of the fall back, as
> well because of the parameters handed over. All printing functions have
> the structure my_print_xxx(const GiNaC::xxx & p, const print_context &
> c, unsigned level) and the print_contexts are without the parameters
> needed for the asymptote output.

The various asy print contexts can have static variables together with 
their set/get methods. So, instead of giving some parameters to the 
printing function you would set your parameters at the beginning with 
mentioned static methods, and then simply filling the stream:

print_asy::set_orientation(90);
print_asy::set_size(100,100,20);
cout << asy << x+y;

Is that possible?

> My new idea, to keep the package as stand alone, but allow all drawing
> functions adopted to the class was to use templates, like
> 
> template <class T> void draw_however(std::ostream ostr, T& obj, ...)
> 
> and specify them like:
> 
> template <> void draw_however<GiNaC::basic>(std::ostream ostr,
> GiNaC::basic& obj, ...)
> template <> void draw_however<GiNaC::basic>(std::ostream ostr,
> GiNaC::mul& obj, ...)
> 
> and so on.
> The problem: all 'obj' are type 'ex'. So it's not working this simple.
> Has anyone an idea how I could fix this? That would be great and solve
> the problems of a permanent implementation in the GiNaC library. Ones
> could simply add it as extra library, if needed.

You'd have to use map functions instead, cf. tutorial sec. 5.5, I guess.

Regards,
Jens