Dear Chris, Chris Dams wrote:
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.
uh oh, yes, I just made a cvs diff to produce the patch and forgot about the new files not in cvs ... Thanks, my fault! Sorry. The missing files are attached. So the standard procedure to read the patch now should be: 1. have a nice fresh and up-to-date GiNaC from CVS-HEAD. 2. unpack the missing-files-attachment to dir ginac 3. apply the patch (patch -p0 < patchfile)
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!
Yes.
(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?
In my opinion, it is the same amount of work. Not more difficult or easier. Currently there are macros called GINAC_DECLARE_FUNCTION and GINAC_IMPLEMENT_FUNCTION that facilitate the function implementation. Not too much difference here. It looks more C++'ish, though. With csgn and conjugate in inifcns.h I experimented with additional macros. It is not finished work in this respect. I guess the best setup finally would be to have several convenience layers (the standard GINAC_DECLARE_REGISTERED_CLASS in case one needs absolute flexibility, the GINAC_DECLARE_FUNCTION for "standard" functions, quick-and-easy macros like GINAC_FUNCTION_1P or maybe GINAC_DUMMY_FUNCTION ...).
(2) Does this affect speed/memory consumption of calculations involving lots of operations to functions? And if so, in what way?
I couldn't measure any speed differences with respect to the original code. Speed is the same. I didn't check memory consumption yet.
(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?
Users will have to rewrite the function declarations and definitions :-( This is what I meant with introducing new incompatibilities.
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.
Inherit, yes. But I don't see how this could help with the step function. Inheritance is good for setting a default behavior for derived classes and to let derived classes access protected member data. Function classes look more C++'ish if you like. At the moment it is impossible to add look-up tables or special methods (like zeta::use_the_other_eval_mechanism() for example) to functions without returning to good ol' C programming style. Regards, Jens