Dear Daniel, Daniel Seidel schrieb:
Now the first version is published as a stand-alone library.
My intention is to include the functions to the GiNaC library. The design is already focused on a later implementation as part of the GiNaC library.
Please have a look. Tarball and Documentation can be found at http://www.maths.leeds.ac.uk/~kisilv/asyforginac.
I would be glad to get some feedback.
there was already some discussion about it between Chris and Vladimir on this list some months ago and after looking at Asymptote and your code/doc I have to admit that I share some concerns with Chris about the inclusion of such code into GiNaC. GiNaC is mainly about algebra with some (large) admixture of numerics. The current output system reflects this: It simply converts algebraic expressions into some line-oriented text, nothing more. Almost none context information is needed for that conversion, so it fits well with the OOP paradigm to let the printing facility be part of the GiNaC classes themselves: Every object/algebraic expression is asked to print itself. With graphical drawing this seems not to be the case. One needs to give numerical ranges for example to the output facility (in most cases). It is (almost) always like "draw(Object, Numerical Range, XYZ Spec)". The bottom line here is, that with graphics there are two possible ways to do it: as part of the classes or outside of them. A priori, none is preferable. But putting them inside the classes has one obvious disadvantage: the code base gets more complex and dependent on other software. And I don't like the idea of having classes that sport say 10 methods for the usual GiNaC stuff and then 10 additional methods just for drawing ... looks like somebody missed the point. So, the question is: what are the advantages and do they outbalance the mentioned disadvantage? I read the remarks in your doc about certain advantages but the details are not clear to me. Have you thought about using some of the visitor-stuff in GiNaC, yet? Regards, Jens