[GiNaC-devel] AsyForGiNaC - an output extension producing Asymptote files
Sheplyakov Alexei
varg at theor.jinr.ru
Sat Aug 19 14:04:40 CEST 2006
Hello,
On Tue, Aug 15, 2006 at 03:39:25PM +0100, Daniel Seidel wrote:
> For the last months I worked, inspired by Vladimir Kisil, on an output
> extension for GiNaC to plot functions with Asymptote.
Frankly, I dislike Asymptote for its home-brew programming language.
It would be nice if Asymptote will be just a C/C++ library, or at
least provide C/C++ API.
> Now the first version is published as a stand-alone library.
>
> My intention is to include the functions to the GiNaC library.
> The design is already focused on a later implementation as part
> of the GiNaC library.
> In the next version this approach should be included into the GiNaC
> library. Therefore the stream manipulator method fct() should
> only call the appropriate draw method implemented virtual in GiNaC::basic.
I don't like adding any virtual methods to GiNaC::basic (actually, I'd
like to get rid of some already existing ones). Leaving aside "aesthetical"
issues (such an approach is completely anti-OO), adding virtual method
costs extra bytes (at least, vtable entry should be stored somewhere)
for *every* GiNaC object. With real-world expressions this translates
into several hundreds of megabytes of RAM wasted for nothing good.
Secondly, drawing is sensible only for small subset of GiNaC classes
(can one draw a tensor? a complex-valued function? etc.), so I can't
see any point in adding them for *all* classes.
Finally, it looks like information available from public interface is
enough (so current implementation works). So why do you need to
add some methods to GiNaC::basic at all?
BTW, I have similar concerns about printing methods. Most of expressions
are never going to be printed (except for debugging purposes), so
turning printing methods into stand-alone functions would save some
non-negligible amount of RAM...
> This allows different draw functions for each class derived from
> GiNaC::basic, respectively.
I think it is better to make this function a template and provide
different specializations for derived classes.
Now comes some sort of bug report:
$ cd example; ./palette
successful finished.
"palette_std.asy" and "palette_man.asy" have been produced
in the subfolder "./output/".
Process these files with asymptote:
>$ asy palette_std.asy
>$ asy palette_man.asy
The files "palette_std.eps" and "palette_man.eps" will be produced.
$ asy output/palette_std.asy
output/palette_std.asy: 42.35: no matching function 'image(picture, real[][], pair, pair, pen[])'
asy output/surface_man.asy
output/surface_man.asy: 78.4: no matching function 'add(picture, picture, pair)'
$ ./surface
successful finished.
"surface_std.asy" and "surface_man.asy" have been produced
in the subfolder "./output/".
Process these files with asymptote:
>$ asy surface_std.asy
>$ asy surface_man.asy
The files "surface_std.eps" and "surface_man.eps" will be produced.
$ asy output/surface_man.asy
output/surface_man.asy: 78.4: no matching function 'add(picture, picture, pair)'
I use GiNaC 1.3.5, Asymptote 1.03, g++ 4.1.2
Best regards,
Alexei.
--
All science is either physics or stamp collecting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20060819/09d86c91/attachment.sig>
More information about the GiNaC-devel
mailing list