Dear Jens,
Vladimir Kisil schrieb:
> "JV" == Jens Vollinga <vollinga@physik.uni-wuppertal.de> writes: JV> GiNaC will _never_ ever DRAW things (unless we link it against JV> OpenGL or something similar ...).
Currently I can use pyGinac interactively to feed through a pipe drawing command to Asymptote and see immediately the result in a GV window, no need to link against any graphic library, popen() is sufficient from GiNaC and Asy does the rest.
my words ... GiNaC never draws anything :-) [DS]you're right. Lets substitute _draw_ by _print_.
[Jens from like two mails ago] ...The only thing needed therefore is - at least to me, correct me if I am wrong - a new printing context. [DS]Including the functions like 'class print_asy : public print_dflt' is not a good idea, because the fallback goes first down the print_context and so instead of using the basic print_asy it will use a print_dflt output if defined. Bad.
JV> Then I have some light concerns about a continuous maintenance JV> of that additional code (we had a similar issue with printing in JV> python format in the past IIRC), ... JV> future. Somebody will have to take care of that, continuously.
This is why I also ad vacating only straightforward functionality in the core GiNaC with a possibility to have more drawing (sorry, printing ;-) methods possibly in a separate library in the anticipated Contrib storage.
[DS]The current code may be enough for the first time. In case you are planning to add an numerical equation solver to GiNaC some extensions may be good. For the first time I think I could fix bugs, if there are some or adjust the output to upcoming new Asymptote version (I noticed that they change some functions incompatible to old versions while programming with an older Manual then my installed version). Even I have to admit being not a real expert.
Even if you don't appreciate the difference between drawing and printing yet ;-), it is significant: using all that is described in section 6.3.3 of the manual, no extra code needs to be added to GiNaC then. It could (and probably will) be added to GiNaC, because it spares the user some extra work, but that's the ONLY reason! The statement put forward in the documentation of AsyForGiNaC and in some emails that the output quality or that the possible drawing capabilities can only be increased if the GiNaC classes are altered is not true.
Maybe you don't agree with this yet, or maybe I oversee something important, but at the moment I think the discussion is at a dead end, since either we agree on some important points (printing in Asymptote format is useful and code can be added to GiNaC), or we disagree but the issue can only be decided with further coding efforts (to explicitly and clearly demonstrate the case).
[DS] Before producing new code we should agree about the design. I hope we agree about the disadvantage of the print_context fallback. The basic thing that should be possible is to write classes derived from GiNaC::basic and adjust printing options, still keeping the unified interface. If you have a better idea than adding the print methods to GiNaC::basic virtually, I would agree luckily. But I don't know how to do it else. If we agree about this things and there's a probable chance the code is added in a further version I could go on implementing it to GiNaC and maybe Vladimir could use it for the cycle class. To write smart functions for the functions like sin, tan ... will probably be a bit more work and I would delay this a bit (or anyone else wants to do it). One more sentence to adding just one asy_print function or asy_print_like_this, asy_print_else, .... I will think about a solution with one function and a parameter. One's should be able to decide which print is wanted by analysing the parameters (if the parameter will have a default value like 'auto') in most cases. But I assume it will lead to difficult checks in the asy_print function and in some cases it is not decidable (3D function surface or palette?). So that's why I prefer one method per output format. It passes responsibility to the user, for him it should be an easy decision, knowing what he wants. Additionally I was thinking about a method asy_print which doesn't specify the drawing format. This can be useful for things like cycle2D, knowing exactly there best output format. For the implementation in GiNaC::basic it should only call the function printing the label. That's maybe worth some more discussion. Greetings, Daniel.