Hi! Jens Vollinga wrote:
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?
Failures that can be traced to changes in the actual hash values are not serious. This is the same issue that was brought up by Jonathan Brandmeyer recently, where he wondered why the PyGiNaC testsuite failed sometimes: <http://www.ginac.de/pipermail/ginac-list/2005-October/000748.html>. 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.
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? Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>