Dear Jens, Am Mittwoch, den 16.08.2006, 18:40 +0200 schrieb Jens Vollinga:
Dear Vladimir,
Vladimir Kisil schrieb:
Dear Jens,
> "JV" == Jens Vollinga <vollinga@physik.uni-wuppertal.de> writes:
JV> GiNaC is mainly about algebra with some (large) admixture of JV> numerics.
Some people like algebraic expressions to be visualised, e.g. gTubalt enriches GiNaC by drawing facilities from Root and everyone seems to like it.
agreed! The only concern I've expressed is whether to have this drawing facility be part of the GiNaC classes or not.
JV> And I don't like the idea of having classes that JV> sport say 10 methods for the usual GiNaC stuff and then 10 JV> additional methods just for drawing
The idea is to add one more printing context "asy" to the "text", "latex", "python", etc. family.
Ah, that is something I was not aware of. I thought that there should be draw, draw_like_this, draw_the_other_way methods added to the classes. So, is it just a new printing context?
Actually I like to add all these functions. Maybe it's really not necessary and belongs more to the scene, rather than the Object. But the basic idea is: an object gets the description of the scene (where the "like_this" is part of) and than knows how to be drawn, or if it is a more specialized object (maybe a GiNaC::function, or something like the cycle2D class of Vladimirs cycle library, which derives from GiNaC::basic), knows how to adjust the scene itself to a optimised picture. So, what can be done o u t s i d e the object is generating mostly all the scene settings (axis, perspective, import, ...), because it doesn't depend on the object. This is currently done by asy::fnctset and it's derived classes. I n s i d e the object the number field (or maybe a smarter graph) should be produced, because some objects like cycle2D, will know how to produce the graph, while an common method (now knowing only how to draw explicit given things) will fail. Also the object should be able (if wanted by the user) to adjust parameters, if it has knowledge about suitable parameters (therefore the optimize parameter is inserted). This feature will probably only become really meaningful with GiNaC::function objects and objects of classes as specific as cycle2D.
JV> most cases). It is (almost) always like "draw(Object, Numerical JV> Range, XYZ Spec)".
Note that here "Numerical Range" and "XYZ Spec" are properties of the scene, not of "Object". Thus there is no need to store all drawing option in the Object. Rather you may prepare an Asymptote scene with required properties and then ask one or several GiNaC objects "print_asy" themselves on this scene.
So, this preparation is done in some global object and later when the GiNaC objects are asked to print themselves they in turn ask (in case the asy printing context is used) this object for certain properties? Is this the plan, roughly?
yes. A asy::options object stores all "XYZ spec" and than a pointer to this asy::options object is passed to the drawing function of the object to be drawn. I.e. the object can access parameters it has to know and (if the user wishes) manipulate some parameters as well (like described above).
A beautiful drawing is always uneasy and will require a lot of customisation. However it will nice if GiNaC will have at least basic possibility to draw a graph of function. It became even more true with development of several interactive wrappers.
True.
Regards, Jens _______________________________________________ GiNaC-devel mailing list GiNaC-devel@ginac.de https://www.cebix.net/mailman/listinfo/ginac-devel