+1 vote

Hi@cbehan@kasper, following code is still invalid

```
{\mu,\nu}::Indices(vector).
u^{\mu}::ImplicitIndex.
u^{\mu}::SelfNonCommuting.
tr{#}::Trace.
ex:=tr{u^{\mu} u^{\mu} u^{\nu} u^{\nu}}-tr{u^{\mu} u^{\nu} u^{\nu} u^{\mu}};
sort_product(_);
```

Version 2.2.9 (build 2310.4b47f18980 dated 2019-12-28), Linux

Ok. In this case, the letters are the same and the free indices are the same which means that a single sort order has not been determined yet. We will need to detect that this has happened and then put an ordering on the set of dummy index topologies.

In the above example, this means deciding whether we prefer {{1,2}, {3,4}} or {{1,4}, {2,3}}. More generally, we should expect to see all possible ways of breaking up {1, ..., 2n} into unordered pairs.

+1 vote

This is now handled cleanly by Dom's new `meld`

algorithm, which is now on github. Instead of `sort_product`

, just use `meld(_)`

. Documentation on this will be in a forthcoming paper.

Thanks. I have used this new algorithm for a while, but there are still some bugs in 'meld' algorithm, for example

```
{\mu,\nu}::Indices(vector).
V^{\mu\nu}::AntiSymmetric.
{{V^{\mu\nu},u^{\mu}}::NonCommuting.
u^{\mu}::SelfNonCommuting.
tr{#}::Trace.
ex:=tr{V^{\mu\nu}u^{\mu}u^{\nu}};
meld(_);
```

the result is zero, it's wrong.