function representation in ginac

[Alexander Frink]

On Mon, 29 Jan 2001, Richard B. Kreckel wrote:
> We had the design you suggest before we switched to the current
> one.  One drawback is that you cannot have classes share the name of
> global functions.  Instead of writing sin(x) we had to write Sin(x).
> IIRC the code was much uglier with the old design and things got clearer 
> when Alex came up with the cpp-register-functions-in-a-vector
> design.  Alex, do you remember the precise circumstances?

Since this decision was made nearly two years ago, I don't remember
the arguments exactly any more. It is possible to write
sin(x)+y if sin is a class, since this is just a constructor
call. However it would not be possible to pass a function pointer as
a function argument (although we don't use such a construct).

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.

OTOH I don't see any advantages using classes for functions.
Mathematical functions rarely inherit something from other
functions, so a flat hierarchy as implemented with the register
function seems to be more natural to me.

Best regards,

Alex
-- 
Alexander Frink                      E-Mail: Alexander.Frink at Uni-Mainz.DE
Institut fuer Physik                 Phone:  +49-6131-3923391
Johannes-Gutenberg-Universitaet
D-55099 Mainz, Germany

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