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