Bug: Dynamic_programming path solver may return illegal contraction path

[refraction-ray]

Tested on GitHub master HEAD.

oem.paths.dynamic_programming([{0,1}, {}], {0, 1}, {0:2, 1:2})
[(1,), (0, 1)] # sth. wrong here
oem.paths.greedy([{0,1}, {}], {0, 1}, {0:2, 1:2})
[(0, 1)] # other solvers return correct result

Though such tensor contraction case is weird and a very corner case, it indeed can occur in https://github.com/google/TensorNetwork/blob/master/tensornetwork/quantum/quantum.py

[dgasmith]

Thanks for the report, let me look into it.

[dgasmith]

Looking into this it appears a pre optimization trigger causes the float to be self contracted (a no-op) and is fixed in #172. As a note the resulting contraction path is perfectly valid, just a bit of wasted effort there equivalent to np.einsum('->', 5).

[refraction-ray]

The new commit on bug/dynamic-singles branch fixes this issue :)

Feel free to close this issue or if you want to keep it open until the bug-fix get merged into master or get released

[dgasmith]

Great to hear- I think we can get a 3.4.0 release out, would you agree @jcmgray?

[jcmgray]

Sounds good to me!