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