function representation in ginac

Richard B. Kreckel kreckel at
Wed Jan 31 18:40:21 CET 2001

On Wed, 31 Jan 2001, Alexander Frink wrote:
> IIRC one of the main reasons against the one-class-per-function
> scheme was that that the preprocessor is not very powerful.
> Since a function can have either default or user implemented
> diff, series, evalf etc. methods, one would need many macros
> implementing all possible combinations. The notation for the user
> to define his own functions would look horrible (at least we
> could not find a better one).
> Further each GiNaC class unfortunately needs some supporting
> code (copy(), destroy(), duplicate() etc.) which would have to be
> generated for each class representing a function again and again
> blowing up code size.

I do not see why all this could not be done by virtual functions.
Am I to be missing some obvious point?

Richard Kreckel
<Richard.Kreckel at Uni-Mainz.DE>

To UNSUBSCRIBE, email to ginac-list at with a subject of "unsubscribe".

More information about the GiNaC-list mailing list