[GiNaC-devel] Bug(?) in reposition_dummy_indices: test case and patch

[Sheplyakov Alexei]

Hello!

On Tue, Oct 10, 2006 at 01:16:21PM +0200, Chris Dams wrote:
> > I don't think your analysis is completely correct. The problem is that
> > 
> > e = e.subs(something) 
> > 
> > calls e.eval(), and eval can change the original expression so that 
> > iterators become invalid. Actually, after the evaluation expression can
> > be *anything*, even not necessarily indexed. For example, the expression
> > in question could evaluate to zero (if someone implements derived class
> > such that for some combination of indices the thing evaluates to zero).
> 
> It is true that an evaluation function can be written such that this goes
> wrong. However, I was assuming that evaluation functions are doing things
> to expressions that make sense. 

First of all, I think it is perfectly sensible for eval() to return zero
(e.g., what about traceless tensors?).

Secondly, your patch does not catch this:
[I admit that example is a little bit weird]

#include <iostream>
#include <stdexcept>
#include <ginac/ginac.h>
using namespace std;
using namespace GiNaC;

int main(int argc, char** argv)
{
	symbol d("d");
	varidx mu(symbol("mu"), d), nu(symbol("nu"), d);

	ex e = indexed(symbol("T"), sy_symm(3, 0, 1, 2),
			mu, nu, mu.toggle_variance(), nu.toggle_variance());
	cout << e << " == > "; 
	e = e.simplify_indexed();
	cout << e << endl;
	return 0;
}

On my system, this gives:

T~mu.nu~nu.mu ==> T~mu.nu.nu.mu

Note that we got invalid expression after the evaluation. 

[snipped]

> Do you know of any evaluation that does make sense where we would 
> encounter this kind of problem? I thought about this, but came to
> the conclusion that this probably cannot happen.

I was trying to implement two classes (derived from indexed) which represent
Riemann and Ricci tensors. I did R~k.i.k.j => r.i.j substitution in
R::eval(). But my code did not work. After a while I found a way to
reproduce the problem with classes which are part of GiNaC.

> On the other hand, as a matter of principle you
> are right that it is best to assume as little about the rest of the code
> as possbile. For this reason I would accept a patch that would do the
> substitutions as they are currently but does not cause eval to be called.

The patch I've posted does that. Is there something wrong/stupid/etc with it?

Best regards,
 Alexei.

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-devel/attachments/20061010/006ecdec/attachment.pgp