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