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

[Daniel Seidel]

Dear Jens,

> Vladimir Kisil schrieb:
> >>>>>> "JV" == Jens Vollinga <vollinga at 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.