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