Suggested master branch fix necessary for "sparse" backend

[emprice]

Hi @jcmgray,

As always, loving this library! I have a use case that makes sense to at least test on the sparse backend. I'm using quimb-1.3.0 (the PyPI version, not the development branch). I noticed that specifying matrices of sparse.COO type is fine until I try to create the MatrixProductOperator or MatrixProductState objects, because sparse.COO.transpose works a bit differently. I was able to fix the problem using autoray, so no new imports on your end. For example, this line becomes

yield Tensor(do('transpose', array, *order), inds=inds, tags=tags)

which can be combined with a quick (on the user side)

import autoray as ar

def sparse_transpose(x, *args):
    return x.transpose(args)

ar.register_function('sparse', 'transpose', sparse_transpose)

to get the correct behavior. I can confirm that this is all that is necessary to create MPS/MPO with sparse backend tensors. I understand if you don't want to fix this on the master branch, since I've been seeing a lot of activity on the develop branch lately; in that case, maybe this "issue" will help someone with a similar use case.

[jcmgray]

Hi @emprice,

As always, loving this library!

Glad to hear it! Thanks for the issue.

---

Yeah as you have found the idea is to route all functions like transpose through the same interface, clearly there are a few places that don't use the syntax:

do('transpose', x, order)

so quimb-side we just need to update those remaining places (actually in the develop branch it looks like this is already done for MPO/MPS).

Then I'm guessing sparse only provides the method COO.transpose rather than the function sparse.transpose. I think we should add sparse_transpose to autoray directly since the idea of autoray is definitely to include these small translations so that the user doesn't have to modify anything at all.

E.g. here's the custom version of transpose for torch arrays:

https://github.com/jcmgray/autoray/blob/ecceb80a6d93d25b262e68c61a8477b72b2a3485/autoray/autoray.py#L671

Would gladly accept a PR for either of those problems, or I will probably get round to them in the next couple of days.

[jcmgray]

I think this should be fixed by jcmgray/autoray#2 - let me know if not!