[GiNaC-devel] new tinfos

[Richard B. Kreckel]

Hi!

Jens Vollinga wrote:

> I am just starting to think about it. Arguments like 'no advantage' 
> and 'no hierarchy' aren't valid anymore, I think.

Well, is there a useful type-hiearchy one could build out of functions?  
And: what could be the advantage of such an approach?  Please show us! 
The wrapper functions are there because you cannot define classes of 
name sin, cos, etc. without running into tons of resolution problems.  
You would have to call the classes differently and add convenient 
functions that return those classes.  That's what we already have, 
except they always return the same type.

> Whether the complexity to define such a class-function is lower, equal 
> or higher than the current one has to be evaluated. I haven't figured 
> out the exact way how such a class-function could be implemented, though.
>
> Stupid question: what are the
> numeric SOMEFUNC(const numeric& ...)
> functions good for? Is it performance? Is it a way to try to separate 
> cln stuff from ginac stuff?

Oh, that is only a more direct evaluation when only numeric evaluation 
is called for.  It's got nothing to do with CLN.  Rather, performance.  
And maybe it's not terribly useful.  But isn't this the same question: 
what is numeric operator+(const numeric&, const numeric&) good for?

> I don't know how to solve the problem of namespace collision/ambiguity 
> with built-in function like sin,cos,... yet. But even in the current 
> implementation a get an ambiguity for stuff like
> cout << sin(1) << endl;
> when both cmath and GiNaC are included and all their namespace members 
> are us'ing'ed.

But that is just a problem with our implementation of ginac/function.h!  
CLN has no such problem, even with newer versions of GCC.  If that is 
really a concern, I suggest simply adding disambiguating explicit 
signatures to the templates that DECLARE_FUNCTION_nP expand to.  It 
cannot be done for all and every combination of them because that would 
be too much code.  But then, we really only need it for 
DECLARE_FUNCTION_1P and DECLARE_FUNCTION_2P, right?

Regards
  -richy.

-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>