ITENSOR: fix of differentiation glitch with contravariant indices
No, I don't think there is an easy fix, with or without AI. That's because it's not really a bug per se: the deep reasons are conceptual. The 'minus sign for covariant indices' was already a hack by yours truly, to manage index ordering for nonsymmetric tensors, but as you (and Claude) have seen, it is not a fully satisfactory solution. The problem is that T([a,-b],[]) can become T([a],[b]) which then ambiguously maps into either T([a,-b],[]) or T([-b,a],[]) and the two are very much not the same:...
Here: (%i1) batch("einhil.dem"); (%i2) "Deriving the Einstein field equations from the Einstein-Hilbert action" (%i3) if get('itensor,'version) = false then load(itensor) (%o3) /home/vttoth/dev/maxima/share/tensor/itensor.lisp (%i4) "We declare the standard metric but remove automatic contraction rules..." (%i5) "... that may incorporate hidden assumptions about symmetry" (%i6) imetric(g) (%o6) done (%i7) remcon(g) (%o7) [g] (%i8) defcon(g,g,kdelta) (%o8) done (%i9) "Let us define the Riemann tensor,...
You've run into a known pathology of rename() and, generally, dummy index handling in itensor. Yes, playing with icounter or the second parameter of rename() can fix things but there's no generic solution. Setting the counter to 100 fixes some, breaks other cases. In particular, I note, your suggested code actually broke einhil.dem. I've now implemented a modified solution with isimplify() taking an optional second parameter and using that in the calls to rename(), but without invoking additional...
ITENSOR: improved index handling in isimplify()
Einhil.dem seems to have index issues
Einhil.dem seems to have index issues
In the current version of einhil.dem, declaration of g's symmetry properties is deliberately delayed, precisely to show their relevance to the final result. So the fact that D does not simplify to 0 is a feature, not a bug.