[GiNaC-devel] function classes

[Jens Vollinga]

Dear Chris,

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.

Chris Dams schrieb:
> GINAC_IMPLEMENT_FUNCTION_OPT(exp_function,
>       print_func<print_csrc_float>(&exp_function::do_print_csrc_float).
>       print_func<print_latex>(&exp_function::do_print_latex))
> 
> This looks a bit too much like the old system IMO. Isn't it possible to
> have virtual functions do_print_csrc_float and do_print_latex? The default
> behaviour of these would then be to print the name of the function
> (prefixed with a backslash in case of do_print_latex) and the argument
> list. Since I found a method virtual const char* class_name() in
> function.h this shouldn't be a problem.

Some kind of macro for the initialization of the static members has to 
be used in any case. So I guess you are more concerned about the _OPT 
part of it, i.e. the print_func stuff. 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 ...

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?

I have (not yet ripe) ideas for print_csrc that are beyond the current 
printing mechanism, i.e. one also wants to evaluate function like tgamma 
or zeta in C programs of course ...
Apart from that, a default that removes the _function suffix should do 
(expect for abs).

> (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?).

> (2) I would like to see a possibility to inherit from another function.
> Maybe by doing something like
> 
> class my_sine : public sin_function
> {
> 	GINAC_DECLARE_INHERITED_FUNCTION(my_sine, sin_function);
> ... etcetera ...
> }

Should be possible. Just needs more macros. Will be done.

Regards,
Jens