commuteinset ignored in id-statement

[nikolai-husung]

The following code is relying on the commutativity of A and B:

NFunction A,B,C;
Symbol w,x;

commuteinset {A,B};

Local test = A(1)*B(2)*C(3);

*** Shouldn't this trigger due to commutativity of A,B? ***
id A(w?)*C(x?) = w*x;

.sort
Print +s;
.end

I would expect the answer to be 3*B(2) but instead I get the initial A(1)*B(2)*C(3). I suspect commuteinset is not taken into account during pattern matching? If this is the "intended" behaviour it should probably be added to the manual in id[entify] and commuteinset. Otherwise this is a bug.

[jodavies]

If the pattern matching code attempts to make this match work and fails, it is a bug. If this pattern is not attempted at all, I suppose it is a "limitation" and possible future enhancement.

Just for information, note that declaring NFunction B,A,C; causes A,B to commute in normalisation, as expected, and then the pattern happens to match.

[nikolai-husung]

This behaviour contradicts the claim that backtracing works fine for functions and is a severe limitation because normally we do not have the freedom to go back and change the order of declaring functions on the fly. commuteinset is taken into account properly when both NFunction are declared to commute with each other, i.e., the order in the id-statement does not matter there as expected.

The current behaviour makes it impossible to ever match with id A(w?)*C(x?) = ...; if there is any number of B in-between. For standard NFunction without commuteinset one could at least use repeat id A(w?)*B(x?) = B(x)*A(w); to impose the desired order but here the normalisation will undo any effect of this.

Warning: With commuteinset, the line repeat id A(w?)*B(x?) = B(x)*A(w); leads to an infinite loop and a crash, which probably is the correct behaviour since the commutativity together with the reshuffling under normalisation restore the initial form over and over.