[GiNaC-devel] function classes

[Chris Dams]

Dear Jens,

On Tue, 18 Apr 2006, Jens Vollinga wrote:

> thanks for your analysis and your suggestions. Currently I am wondering 
> if it would be a good idea to open a special CVS branch for the function 
> class modifications. With that the release of a GiNaC 1.4 would not be 
> delayed or poisoned by these big modifications and the development of 
> the function classes would proceed more publicly.

Yes, I think that is a good idea. Do you plan to release 1.4 soon? I still
have some changes in my local CVS-tree that I would like to see going into
it, but that I would like to test a bit more before comitting them.
Unfortunately, it involves adding two new functions and two new function
options, all coded within the old system, of course... :-(.

And you will also have to document your new tinfo-system. The tutorial
still uses the old one.
 
> If one wants to keep the double dispatch mechanism alive for function
> classes, there is not much else one can do but to use a macro such as
> the one displayed above. Simple overloading won't do. Of course, the
> function class itself could sport good defaults for all functions and
> thereby making the use of the considered macro unnecessary in most
> cases. This is what you are proposing, but what I found difficult to do.
> For print_latex I can imagine two alternatives: \functionname or
> \mbox{functionname}. Most built-in functions use the former, but most
> user defined ones probably want to use the latter ...

Yes, I think the function class should provide good defaults.
 
> Maybe the following would do: have a (not complete) list of 
> latex-built-in functions and the default latex printing functions 
> chooses the \func variant in case the name is in the list, otherwise it 
> chooses the \mbox variant. Too bloated?

There could be an implementation using GINAC_IMPLEMENT_FUNCTION_OPT for 
built-in functions and the default \mbox{functionname} for user-defined 
ones. On the other hand, considering the fact that after it a "(" will
come, I think \mbox{functionname} is not too bad as an implementation even 
for, say, the sine.

> > (1) It should be possible to declare a function without the _function
> > suffix. The three reasons that you mention for the need of the suffix do
> > not apply seem to apply to most user-defined functions, so I think it is
> 
> yes, but ...
> 
> > good if users can avoid having to suffix every function they define. This
> > would avoid having to have code like
> > 
> > 	ex thing(const ex& x1)
> > 	{
> > 		return thing_function(x1);
> > 	}
> 
> maybe there are also advantages of a consistent naming scheme. At first 
> I had only built-in functions with the _function, or _ginac as richy 
> suggested, extension that collided with cmath functions and all other 
> functions went without it. Then I thought about defaults for printing 
> and because I didn't want to have the _function part of the name 
> automatically removed for user defined functions (maybe he *really* 
> wants a function to be named BLA_function and also printed like that 
> ...) I had to write printing functions for almost _every_ built-in 
> function. It looked kind of short-witted. Then I thought about the 
> inconsistency for the user: if he uses for example is_exactly_a<> for 
> built-in functions he has to append _function to the name otherwise not. 
> Maybe the user chooses a name for his function that is already in cmath 
> (or any similar dominating header ...), then he might get some subtle 
> errors in his programs like the ones that are avoided by the special 
> naming for built-in functions. So in the end I chose to treat every 
> function the same. But I am still not satisfied with this and I like 
> what you are proposing! So I will re-think this decision. Maybe some 
> other trick will do (namespaces?).

Hmmm... It sounds like every solution has disadvantages. Yet another ugly
idea: a function that is declared as thing_function, has
GINAC_DECLARE_FUNCTION also emit the code friend ex thing(const
ex&x){return thing_function(x);}. Note the use of "friend" to be able to
declare an ordinary function inside a class body.
 
Best,
Chris