[GiNaC-devel] new tinfos

[Richard B. Kreckel]

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