[GiNaC-devel] new function system

[Jens Vollinga]

Hi,

Richard B. Kreckel wrote:
> What about this alternative:
> 
> Name the classes sin_t, log_t, tgamma_t (or some other uniform scheme) 
> and provide functions sin, log, tgamma that return objects of these 
> classes.  The advantages are that people a) don't have to rewrite too 
> much code and b) we don't bother our users with yet another convention 
> for naming mathematical functions.  Does that sound reasonable?
> 
> Though, I totally agree with your earlier sentiment that in the general 
> case we shouldn't worry too much about name clashes and instead we 
> should put the burden of disambiguation on the user.  But in special 
> cases where there are conflicts with functions of built-in integral 
> type, I think it is just fine to disambiguate in favor of the GiNaC 
> functions by adding an explicit signature.  This way, sin(1) stays what 
> it is: sin(1) (well, sin_t(1) or function(42,1) or whatever) and does 
> not become 0.84147...

sorry, I don't fully understand your proposal, yet.

Why should the user have to learn another convention (as stated above 
under b)) if all the classes have the same name as the current functions?

Why is it fine to disambiguate just in case of integral types (see 
question below)? sin(1) doesn't disambiguate currently when one includes 
cmath!!

Does it really make sense to have sin(1) or zeta(2) evaled on creation 
(by means of a special function)? I remember having to 'tweak' zeta a 
little bit to not throw an exception when the argument is 1. And with 
the polylogs I often have to use a lot of .holds() just because I don't 
want the automatic evaluation in intermediate expressions. And isn't 
there an issue with 1/tgamma(-n) ...? Maybe a solution to this is easier 
without the automatic evaluation on creation.
To have automatic evaluation just on assignment might (I am not sure 
though, please teach me!) be more clear, powerful, ...

Regards,
Jens