Feat: tensorfy via rank-width

[kuyanov]

Efficient implementation of tensorfy() based on my dissertation "A Rank-Width--Based Approach to Quantum Circuit Simulation via ZX-Calculus". Added the following components:

1. File pyzx/linalg.py - class REF (Row Echelon Form) for efficient cut-rank calculation, as well as some other helpers.
2. File pyzx/rank_width.py - heuristics for finding good rank-decompositions (greedy-b2t and greedy-linear) and the recursive tensor contraction algorithm.
3. File tests/test_rank_width.py - verifying correctness of the simulation against the current (naive) tensorfy.

Now tensorfy takes an additional kwarg 'strategy' (defaulting to 'naive'); the new routine is accessible with tensorfy(g, strategy='rw-auto').

[jvdwetering]

Hi kuyanov, this looks great. More intelligent support for tensor contraction has been a thing that has been on the list essentially forever. Just a couple of things, since I've been trying to be a bit better at ensuring code quality before things are merged in: there's a couple of methods you introduce that don't have docstrings, and also certain parameters don't have a mypy type set.
Additionally, you add a new requirement galois and use this only to calculate a generalised inverse of an GF2 map if I'm not mistaken. Maybe this is too much of a hassle, but can't the existing Mat2 class do something similar already? It can at least calculate an inverse, how far away is that from doing a generalised inverse?
Or is this galois package not that big a package to add to the requirements?

[jvdwetering]

Also, not sure how much sense it makes for this feature, but in order for people to actually find this and use it, it is useful to point out its use somewhere. For instance adding a notebook in the demos folder demonstrating cases where certain strategies perform better than others. Or even just a note in the demos/AllFeatures notebook that there are other strategies for contracting with a link to the appropriate place in the documentation.

[kuyanov]

Hi kuyanov, this looks great. More intelligent support for tensor contraction has been a thing that has been on the list essentially forever. Just a couple of things, since I've been trying to be a bit better at ensuring code quality before things are merged in: there's a couple of methods you introduce that don't have docstrings, and also certain parameters don't have a mypy type set. Additionally, you add a new requirement galois and use this only to calculate a generalised inverse of an GF2 map if I'm not mistaken. Maybe this is too much of a hassle, but can't the existing Mat2 class do something similar already? It can at least calculate an inverse, how far away is that from doing a generalised inverse? Or is this galois package not that big a package to add to the requirements?

No problem, I will add docstrings to all functions. Galois is not much of a problem, yet I was thinking of getting rid of it for a long time due to performance issues. I will modify rank_factorise(...) so that it can return the inverted factors instead, which is more efficient than just calling .inverse() on them.

[kuyanov]

Also, not sure how much sense it makes for this feature, but in order for people to actually find this and use it, it is useful to point out its use somewhere. For instance adding a notebook in the demos folder demonstrating cases where certain strategies perform better than others. Or even just a note in the demos/AllFeatures notebook that there are other strategies for contracting with a link to the appropriate place in the documentation.

I see the BenchmarkQuimb notebook already contains benchmarks of tensorfy against Quimb. I guess it'd be a good place to add the comparison?

[jvdwetering]

Also, not sure how much sense it makes for this feature, but in order for people to actually find this and use it, it is useful to point out its use somewhere. For instance adding a notebook in the demos folder demonstrating cases where certain strategies perform better than others. Or even just a note in the demos/AllFeatures notebook that there are other strategies for contracting with a link to the appropriate place in the documentation.

I see the BenchmarkQuimb notebook already contains benchmarks of tensorfy against Quimb. I guess it'd be a good place to add the comparison?

Yes, that sounds like a good place. Maybe we can then also change the name to something like BenchmarkTensorContraction or something.

[kuyanov]

BenchmarkTensorContraction is finally complete - it is based on the former BenchmarkQuimb with classes CircuitBenchmark and QuimbStrategies merged into one. Also, added a reference in AllFeatures so that the user is more likely to see it.

[kuyanov]

Overall, the rank-width methods turn out to be more reliable in general. The naive approach has a better constant in some cases, but sometimes it is exponentially slower.
Also, there is the flow-based approach, described in my dissertation, which is not yet integrated - I need some additional information from the simplification process, like pairs of vertices for which pivot was called. Once done, it will have even better performance on random circuits, according to my benchmarks (see https://github.com/kuyanov/qsim-ZX/blob/main/results/bench-random/CNOT_H_T_Q10_time.png)