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