[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: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20060819/09d86c91/attachment.pgp


More information about the GiNaC-devel mailing list