[GiNaC-devel] new function system

[Jens Vollinga]

Hi,

Richard B. Kreckel wrote:
> Oh, you aren't proposing logGamma, etc. any more?  Good.  (And, please 
> excuse my misunderstanding you.)

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).

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

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

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

> 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? So the point we are 
arguing about it whether more specializations in order to prevent 
ambiguities should be added?

Regards,
Jens