Feature: Feynman path integral simulation capabilities

[WrathfulSpatula]

If I understand the state of research and theory, any "Schrödinger method" QC simulator definitely uses the Hamiltonian mechanics approach. Further, I think "tensor networks," which we might have some simple use of in QUnit, are akin to "field operators" and use the Lagrangian mechanics. However, Qrack seems to be missing any Hamilton-Jacobi mechanics, or the Feynman path integral approach. (I've written entirely Feynman path integral based general quantum system simulation software long in the past, by the way, AKA the "Metrix" project, which was private and is long "dead," superseded in all practical manner by Qrack.)

Again, if I understand, Qrack's avoidance of Feynman path integrals is largely an intentional design choice: Qrack's quantum state can be queried at any point in its time evolution after the application of any gate, whereas Feynman path integrals calculate an action for each potential time-evolution trajectory, such that this approach might not be queried as immediately stateful "in-flight." However, I see no problem with wrapping time evolution point-to-point trajectory over a circuit in a special interface that does not have an immediately queryable state, even as a temporary layer to wrap the standard QInterface type for limited sequences of gates, then releasing the QInterface, hopefully.

I'll definitely be experimenting with this after a literature search and review, now.

[WrathfulSpatula]

I've just started the literature search, but it looks like our "sparse state vector" can potentially be interpreted as a Feynman path integral approach of sorts. (A very simple, but good, explanation can be found here.) In fact, use of our sparse state vector feature already theoretically benefits from acting gates iterated only over nonzero amplitudes, when they are small enough in number relative to "saturation" of all amplitudes being nonzero.

An obvious caveat to the use of a sparse state vector is that it is fully "saturated" even by just parallel H gates across every available qubit. However, with QUnit on top of the sparse state vector, the representational separability of a reset qubit register under this operation is fully maintained, and automatic basis switching from |0>/|1> to |+>/|-> does not even "branch" the nonzero amplitudes at this first step!

The obvious limitation of our sparse state vector under the QUnit layer, I know, is that it is not OpenCL-accelerated. However, given that it already synergizes very well with QUnit, perhaps I should make another pass at optimizing it, if not ultimately even porting it to GPGPU.

[twobombs]

Porting the sparse state vector functionality to GPGPU might just help to make the afore mentioned supremacy benchmark almost trivial to run on a run-of-the-mill GPU. It is those optimisations that make QC tech and methods more avaliable, cost effective and for general use. IMHO it is almost boring to 'prove' supremancy because 'it needs a boatload of memory' ( and not compute; what the name in quantum compute otherwise would indicate ) nice article on arxiv indeed. Reasonably good to follow for a noob like me :) I once saw Susskind do a talk about something similar. I'll look it up.

[twobombs]

However, I see no problem with wrapping time evolution point-to-point trajectory over a circuit in a special interface that does not have an immediately queryable state, even as a temporary layer to wrap the standard QInterface type for limited sequences of gates, then releasing the QInterface, hopefully.

I'm very interested at what timescale you think. is this on planck-scale ( simulation style ), real time ( effectively skipping states ), or the abstract T + 1 ?