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

[Daniel Seidel]

Dear Jens,

Am Montag, den 21.08.2006, 14:28 +0200 schrieb Jens Vollinga:
> Dear Daniel,
> 
> Daniel Seidel schrieb:
> >> [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.
> 
> currently I am thinking this is good. Maybe I can convince you as well. 

I agree with you that it is a good idea for the existing output formats,
because it's really better if the mathematical expression remains, than
printing something like [GiNaC-Object] and I have no doubts about this
being a good solution.
But, concerning the output for asymptote it will be different. Because
usually it should not print only the formula, it should print the
description of a graph. So at the end (after processing the output file
with Asymptote there should be a picture. The text produced from
asy_print is far more then the formula. It is code for Asymptote, which
describes how to draw. This produced output doesn't even necessarily
have to include the literally written formula, that would be produced
from all other print_context. So the code would not be useful at all.
 
> Let's look at latex format. There you have
> 
> class print_latex : public print_context
> 
> In case a class doesn't handle print_latex (some developer was lazy, for 
> example) it defaults to "normal" printing. It doesn't raise an 
> exception. In lots of cases the "normal" output is no valid latex 
> syntax, so the latex interpreter will complain. But still you have the 
> full output. You could load the output in some text editor and fix the 
> output quite easily.
In this case really true.
> 
> If after some long calculation somebody's program starts to print its 
> (often comparatively small) result and just "crashes" with an exception, 
> lots of somebodies would probably be very annoyed. They could file a bug 
> report and wait until somebody fixes the source code (the advanced user 
> may correct the bug(?) for himself, of course). But the aforementioned 
> option to correct the buggy output in some text editor is not possible. 
> Essentially they would have to (wait for help and then to) run their 
> program again.
why should it crash more often? (just because I don't understand this)
> 
> The same is probably true for asymptote output. There you would just get 
> let's say a "sin(x)" for example instead of some more elaborate 
> asymptote code. Either Asymptote will complain or produce bad graphics 
> then. But it is very likely that one is able to fix that afterwards with 
> some search and replace (and then file a bug report, of course).
No. See explanation above.
> 
> > [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
> 
> Let's say you do something like
> 
> class print_asy : public print_context
> class print_asy_differently : public print_asy
> class print_asy_even_more_advanced : public print_asy

I doubt that this is a good idea, not only because of the fall back, as
well because of the parameters handed over. All printing functions have
the structure my_print_xxx(const GiNaC::xxx & p, const print_context &
c, unsigned level) and the print_contexts are without the parameters
needed for the asymptote output.
> 
> then you could define functions like
> 
> mul_print_asy()
> add_print_asy_differently()
> ...
> 
> at first separately from GiNaC sources (later these functions could be 
> made member functions, NON-VIRTUAL member functions, cf. 
> basic::do_print_tree()),
> 
> and then gather commands like
> 
> [weird stuff].print_func<print_asy>(&mul_print_asy)
> ...
> 
> in some central source file.
> 

My new idea, to keep the package as stand alone, but allow all drawing
functions adopted to the class was to use templates, like

template <class T> void draw_however(std::ostream ostr, T& obj, ...)

and specify them like:

template <> void draw_however<GiNaC::basic>(std::ostream ostr,
GiNaC::basic& obj, ...)
template <> void draw_however<GiNaC::basic>(std::ostream ostr,
GiNaC::mul& obj, ...)

and so on.
The problem: all 'obj' are type 'ex'. So it's not working this simple.
Has anyone an idea how I could fix this? That would be great and solve
the problems of a permanent implementation in the GiNaC library. Ones
could simply add it as extra library, if needed.

Greetings,

Daniel.