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

[Jens Vollinga]

Dear Daniel,

Daniel Seidel schrieb:
>> 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.

Necessary or not? That's the key issue. If you like to add all these 
functions then we are back at my initial objections.

> 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.

This is something I don't really understand yet. Let's say we have an 
object 'sin(x)'. Now, how does this object know how to draw itself?!? 
That's only possible if you supply some numerical value for x. And if 
you supply numerical values, then I see no difference between "let the 
object draw itself" and "do an evalf from the outside and plot the 
returned value (also from the outside)" just that the first option leads 
to a "pollution" of the class interface.

> 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.

Is there something else involved than using the numerical value of an 
expression at certain evaluation points?

Or to put it differently: what _HIDDEN_ information from GiNaC classes 
do you actually need for drawing with Asymptote?

Regards,
Jens