[GiNaC-devel] new tinfos

[Jens Vollinga]

Hi,

I want to share some findungs about the new tinfo mechanism I proposed 
lately:

In principle, it works! The return_type_tinfo() methods have to be 
changed a little bit, because the bit pattern arithmetics done for 
clifford and color classes (there, tinfo is combined with the 
representation label) are no longer possible. The quick and dirty fix I 
made for that should cause a slight performance loss, but I was not able 
to measure one, yet.

In practice, there is a problem: Two checks fail. One check is the 
normalization check:

	e = (pow(x, 2) - pow(y, 2)) / pow(x-y, 3);
	d = (x + y) / pow(x - y, 2);
	result += check_normal(e, d);

Since now the tinfos do change from compilation to compilation, also the 
hash values do change. So the canonical ordering can be different and 
normal seems to be very dependent on that ordering.
In 50% of the cases the check fails, because the normalization returns
(x+y) * pow(-x+y,-2),
which is correct but doesn't compare well.

The second check that fails is from the clifford checks:

	e = dirac_gamma(mu, 0) * dirac_gamma(mu.toggle_variance(), 1) *
             dirac_gamma(nu, 0) * dirac_gamma(nu.toggle_variance(), 1);
	result += check_equal_simplify(dirac_trace(e, 2),
                   canonicalize_clifford(e)); // e will be canonicalized
                                         by the calculation of the trace

Here sometimes (like every third invocation) canonicalize_clifford(e) 
returns a wrong result:
(dirac_gamma.nu*dirac_gamma.mu)*(dirac_gamma^nu*dirac_gamma^mu)
The mu and nu are swapped!

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

Regards,
Jens