search

Jutho / TensorOperations.jl

Julia package for tensor contractions and related operations
https://jutho.github.io/TensorOperations.jl/stable/
Other
443 stars 56 forks source link

Introduce planarsort for contraction indices #90

Closed mhauru closed 3 years ago

mhauru commented 3 years ago

As discussed. I'm marking this too as a draft PR, because I assume you want reorganise things, maybe turn this into a completely new macro.

This also breaks some of the tests, which use == for comparison and rely on two different ways of calling a contraction end up doing the exact same thing, because now some internal extra permutations may be introduced, after which only ≈ holds. Those extra permutations may, of course, also be wasteful when dealing with non-anyonic tensors.

Jutho commented 3 years ago

Look's very clean, but I will have to study this in a bit more detail.

Jutho commented 3 years ago

Very clean code and very useful; thanks.

So if I understand correctly, this tries to determine the order of the dangling edges leftind and rightind for any subpart of the contraction network. However, it always produces sensible results and never errors out. I assume the errors then come in TensorKit.jl, whenever a permutation is not cyclic, meaning that errors come at runtime (when trying to evaluate the contraction) and not at macro expansion time. However, it could be at macro expansion time as well, the macro has all the information it needs?

I am wondering if the whole functionality related to planar diagrams should go to TensorKit.jl; it's not really relevant for generic arrays right?

mhauru commented 3 years ago

So if I understand correctly, this tries to determine the order of the dangling edges leftind and rightind for any subpart of the contraction network. However, it always produces sensible results and never errors out. I assume the errors then come in TensorKit.jl, whenever a permutation is not cyclic, meaning that errors come at runtime (when trying to evaluate the contraction) and not at macro expansion time. However, it could be at macro expansion time as well, the macro has all the information it needs?

Indeed. If you try to contract a non-planar diagram the error is a runtime error from add!, saying some permutation can't be done without braiding. This certainly isn't optimal, if for nothing else then because it's quite obscure which part of the contraction is giving the error. I've often manually called @macroexpand on my @tensor expressions just to debug these non-planarity errors.

So yes, having the error happen at macro expansion time would be an improvement. I wonder how far one could get if in all the cases where I currently just have the planarsort function return the original leftind and rightind, we would just raise an error? I haven't really thought through what exactly planarsort does if the combinatorial map isn't planar, like are there cases where planarsort still manages to go through without an error, but the resulting contractions would generate an error further down?

I am wondering if the whole functionality related to planar diagrams should go to TensorKit.jl; it's not really relevant for generic arrays right?

Yes, that does sound reasonable. Are you at the moment thinking of making this a new macro?

mhauru commented 3 years ago

Closing, since TensorKit now has this functionality implemented.