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

[Daniel Seidel]

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 at 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 at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-devel