[GiNaC-devel] function classes

[Jens Vollinga]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newfiles.tar.bz2
Type: application/octet-stream
Size: 32091 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20060414/8fab4f23/attachment.obj>