[GiNaC-devel] new function system

[Richard B. Kreckel]

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/>