[GiNaC-devel] new tinfos

[Jens Vollinga]

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