Confusing behavior of "compute_all_marginals_via_slicing()" in experimental module

[apiedrafTNO]

Hello,
I encountered what seem like very suspicious behavior of the method compute_all_marginals_via_slicing().
I want to preface this by saying that I am most likely misunderstanding that the method does.
In my mind, computing the marginals of a set of output_inds means selecting an output index, returning the result of contracting all but the selected index, and cycling over all output_inds. That is, the otput should be a list of vectors.
I'm interested in this because I'm using tensor networks to encode classical probability distributions over many variables, and I would like to have a method to marginalize those variables (represented by edges) without repeating computations.

I have made a small example network with 4-5 tensors and 8 edges. When I try to compute marginals using the method in question, I manage to do so for some sets of edges, while I get an error for other combinations. It seemed at first that it was internal edges that gave an error, while marginalizing the external edges returned some numbers (which seem wrong).

I created a notebook with all the code and the errors that it throws me (see attached pdf). At the end there is a naive function that I made that also computes marginals. I'm pretty sure that that function correctly compute what people understand by marginals (sum out everything but one variable/index), and you can see how the numbers are completely different.

marginals_test.pdf

The errors seem to go all the way down to einsum not assigning the right shape to the resulting arrays while slicing. I checked the kwargs like the error message said but it didn't help me much. Also, notice that before the error messages I get a warning for not using kahypar. That is because I'm running it on a windows computer. Yet, there seems to be a crude optimizer in place, and the network is so small that kahypar is certainly not needed. Still, Could that be the issue?

[jcmgray]

Sorry I missed this! For posterity, the problem is that the network has lone dangling indices. When the initial contraction tree is created, these indices are trivially summed over, and this actually happens in a 'pre-processing' step that is not part of the main contraction in cotengra since they are not a pairwise contraction. For some reason this is not compatible with slicing those indices, I will try and work out. However, the functionality is in the experimental module for a reason!

[jcmgray]

This should be fixed by : jcmgray/cotengra@4327003.