Hi! Jens Vollinga wrote:
Well, I wouldn't be unhappy if tgamma would be renamed to gamma, but I don't care too much. So, I don't propose it (anymore).
Whatever. The name was chosen in anticipation of a future revision of the C++ standard. All we had back then was the C99 standard which named the two functions tgamma and lgamma. It appeard natural to assume that C++0x would eventually follow. Also gamma(x) was deemed to be a conflict with the derivatives of Riemann's zeta function.
Well, I was just suggesting to disambiguate the common cases like ex sin(int) in order to reduce the number of surprises. What else could one override? ex sin(double)? No! That would really conflict with cmath's declaration. (Note that CLN has sin(own types), as have many other such libraries).
Just to understand it: This disambiguation is not in GiNaC right now, but you propose it to be done like in your email posting from 2001? This probably got me confused and therefore I mentioned sin(1) etc...
All I propose is to add a few additional signatures for ex GiNaC::sin(<built-in integral-type>) such that it is preferred over the definition in the <cmath> header file when there would otherwise be a conflict. I suppose this is independent of whether the thing is a true ctor or a helper function returning an object representing a function in a symbolic way. (E.g. sin(ex) returning a sin_t object, maybe.)
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.
You mean: to actually _throw_ an exception, I suppose?
Forget about the eval on creation stuff I wrote. I got confused there, too. But, to NOT throw an exception in the case of arg=1 was a correct statement.
But why? The zeta function has a simple pole at x==1 that goes like 1/x. With the same reasoning we should get rid of the exception thrown by tan(Pi/2) and all other pole_errors. Now, series((x-1)*zeta(x),x==1,2) returns zeta(1)*(x-1)+Order((x-1)^2). This is less helpful than 1+Order((x-1)^2).
expressions. And isn't there an issue with 1/tgamma(-n) ...?
What issue? Limits are quite another story, aren't they?
No, I meant 1/tgamma(-2) for example. Should be zero, I guess. But GiNaC doesn't like it and throws up ...
But this is precisely the issue of limits! Why should it be zero? After all, there is a simple pole in the denomiator. It makes perfect sense to stuff it into a Laurent series expansion, though. Indeed, series(1/tgamma(eps-2),eps==0,1) correctly returns Order(eps). If we had a limit command, then limit(1/tgamma(x),x==-2) should return 0, all right. Until then, Laurent series expansion must hold as a substitute for limits. Whether the approach to base the series expansion on limits is more fruitful than the other way round, I don't know. I think both ways work. If we want to deal with the Riemann sphere instead of just the complex numbers, then 1/tgamma(-2) should indeed be zero. But then we would have to add ComplexInfinity to our constants and make the corresponding adjustments to add, mul, etc. in order to avoid errors that would follow from rewriting ComplexInfinity-ComplexInfinity as 0. That is certainly possible.
I don't understand: Each class has two evaluations: ctor and eval. The ctor cannot do everything because it is contrained to a specific class. The eval member functions, in contrast, have more leeway with the general ex they return. The intent was to do as much term rewriting as possible in the ctors, and do as much term rewriting as reasonable in the eval member functions. Maybe that is questionable, I don't know. However, all this doesn't hold for our functions, does it? We have sin(ex) invoking the ctor function::function(unsigned ser, const ex & param1) which doesn't do anything intersting. (This also accounts for the behavior described in <http://www.ginac.de/FAQ.html#evaluation>.)
As stated above, I got a little confused %^) The new class-functions would not change anything here, or would they?
Right. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>