[GiNaC-devel] AsyForGiNaC - an output extension producingAsymptote files

[Daniel Seidel]

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

The function couldn't just produce a number field. It could choose only
several point, like lets say in case of 'sin x' every PI interval maybe and
connect them with other operators, adjusting tension. This would lead to a
smaller output file and less calculation effort. The situation gets more
interesting thinking of functions with poles (currently the standard 'tan x'
output looks awful) or if you go to things like cycles, being having not a
unique value f(x) anymore. I think than it's useful or even necessary to
have special information.

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