[GiNaC-devel] function classes

Chris Dams C.Dams at science.ru.nl
Tue Apr 18 12:28:57 CEST 2006


Dear Jens,

I have looked again at your patch and have come to the conclusion that I
like the idea. Nice job! What I do not like so much is that one still has
to type things like

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.

I still have two wishes regarding the function system. If you like you
could implement them, or somebody else could, but before declaring the
greatness of the new system, I would like to be sure that there are no
fundamental reasons why this couldn't be implemented.

(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
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);
	}

(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 ...
}

Concerning your own objections regarding the function factories. I think
it is not so bad provided somebody implementing new functions does not
have to worry about them. I.e., they should remain behind the screens.
Looking at your implementation this indeed seems to be the case.

Best,
Chris



More information about the GiNaC-devel mailing list