Hi, Richard B. Kreckel wrote:
I don't know how to interpret these failures. Is the new tinfo mechanism doomed? Is there a bug in canonicalize_clifford and the normalization check is flawed?
The same can happen when the serial numbers of symbols change because an additional symbol is created earlier on in the program. Or one symbol less. This has nothing to do with your tinfo-ideas: I would suggest to change these exams in the testsuite by calling expand(), normal() or doing additional index contraction, respectively. The way they are written right now is not good, especially from a didactical point of view. People should learn not to rely on random behavior.
Good. Then I only have to re-examine the canonicalize_clifford difference.
The reason to think about a new tinfo mechnism for me is the idea to get rid of the current function class and replace it by a every-ginac-function-is-class way of doing it.
I made an attempt in that direction several years ago. It didn't go too well: <http://www.ginac.de/pipermail/ginac-devel/2001-June/000259.html>. But then, maybe you're up to something different. Could you elaborate a little on your ideas?
I am just starting to think about it. Arguments like 'no advantage' and 'no hierarchy' aren't valid anymore, I think. 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? 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. Regards, Jens