[GiNaC-devel] function classes

[Chris Dams]

Dear Jens,

On Thu, 13 Apr 2006, Jens Vollinga wrote:

> Things I don't like too much about it are:
> - function classes have to follow a naming scheme like sin_function,
> cos_function, etc. Reasons to have such a naming scheme: 1. cmath puts
> its functions mercilessly into the global namespace. 2. function names
> and function method names must not be the same. This is important for
> conjugate for example. 3. To avoid problems with the built-in global
> ginac functions with numeric arguments.
> - in order to make input_parser work, there has to be a look-up between
> function names and some kind of factory. This kind of reproduces the old
> function system within the new function class system (the patch (ab)uses
> class_info mechanism to save these information).
>
> I am currently not sure whether it is worth introducing this new
> function system because of the problems mentioned above, the code
> incompatibility it introduces and maybe some other disadvantages not
> foreseen by me.

I find your patch difficult to read. Maybe a unified or context diff would
be easier. Also, you mention cos_function but I was not able to find
the pharse "cos_function" in your patch, which confuses me. I was looking
a bit at the function factory, but there I find one reference to
registered_class_info. If there is only one reference to something in C++,
it shouldn't compile... Therefore it seems that the code you posted is far
from all that you have. IMHO a new system for funtions should be judged on
the following grounds
(0) Can one still simply type "sin(x)" to obtain the sine of the symbol x.
Judging the patch to exam_pseries.cpp this should be possible because it
also seems to work for log(something). Good!
(1) Does it become easier or more difficult to implement new functions?
As I was not able to find the new implementation of, say, the exp in the
new implementation I cannot judge. The entire contents of the file
inifcns_trans.cpp seems to be deleted but where is a new version of it?
(2) Does this affect speed/memory consumption of calculations involving
lots of operations to functions? And if so, in what way?
(3) How easy/difficult is it for users to port their existing functions to
the new system? Again, I would like to see the code implementing e.g., the
sin to judge this, but where is it?

Then there is the point "if it ain't broken, don't fix it". What are the
advantages of the new function system? Is it for instance possible to
inherit from an existing function and add some properties? E.g., as
discussed with Vladimir earlier it could be nice to be able to add
step(x)^2 -> step(x) by inheriting from the step function.

Best,
Chris