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