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?