[GiNaC-devel] GiNaC and Asymptote

Chris Dams Chris.Dams at mi.infn.it
Mon Apr 24 13:19:19 CEST 2006


Dear Vladimir,

On Fri, 21 Apr 2006, Vladimir Kisil wrote:

> 		With so many exciting activity going around GiNaC already 
>   I wish to propose even more. Why do not let GiNaC classes to visualise
>   themselves?
>
>   [... SNIP ...]
> 
>   I think it would be worth to integrate GiNaC with Asymptote. As a
>   start I think to add a method .asy() to the GiNaC::basic which simply
>   put a label at specific position with LaTeX representation of the
>   object. For functions it would be rewritten by a method which try to draw its
>   graph (if this is possible). 
> 
>   If the general perception is that this is worthy I may try to produce
>   an initial patch.

I think I do not really understand very well in what cases this would be
useful. The point of computer algebra is to be able to handle very large
expressions, including ones that one wouldn't want to see printed and/or
visualized. If I understand correctly, the use of interfacing with
Asymptote would be to e.g., print labels that are formulas. However, in
order to be readable these need to be rather small. In that case using
(La)TeX gives much more control over the appearance of the formulas.
However, imagine the result of a very complicated calculation is x-y and
that result would need to occur somewhere in a figure. Fine as such but in
that case I would almost always like to control how this result appears
precisely. E.g. I might prefer to see x-y instead of -y+x. It becomes even
worse if one imagines fractions. I generally very much prefer to see x/y
in printing than y^(-1)*x. Besides, what if it turns out that this was
coded in such a way that a new version of GiNaC yields a much more
complicated representation of x-y, one that is to big to be contained in
the figure. This would mean that the user needs, in order to regenerate
his image, to debug his symbolic calculation. Not so much fun .... Having
the result in (La)TeX would be much more stable.

Best,
Chris



More information about the GiNaC-devel mailing list