Closed WrathfulSpatula closed 1 year ago
Natively, Qrack enacts "a full gate at once." For example, when I enact an ideal logical Pauli X gate in Qrack, I don't think at all about the time it takes to enact the gate or the Hamiltonian that real hardware evolves the quantum state by over this time; the operation is "atomic," in the computer science sense. Our first consideration is that an ideal Pauli X gate, for example, now takes a finite amount of (proper) time.
It's natural to think of this gate being enacted in finite time as proceeding in finite difference simulation time steps via the TimeEvolve()
DLL API method, according to a Hamiltonian and a time parameter. However, what is the Hamiltonian we use? It's actually arbitrary and hardware-specific, so long as we arrive at a full Pauli X gate, for example, over an expected length of time. Then, the "cleanest," "ideal" Hamiltonian (or at least one arbitrary Hamiltonian that will work) could have the effect of evolving through time as a continuous linear interpolation over roots of the Pauli X gate, from 0 to 1 at the ends of the length of time we expect (or define) the quantum computational gate to take. We can always accomplish the root of an arbitrary gate with a 3-parameter unitary "U
" gate, with or without an arbitrary set of control bits, rather than the TimeEvolve()
method.
If the "RealtimeQasmProgram" in Unity becomes monolithic, this way, we'll consider pulling it back into the Qrack library directly, potentially giving us more opportunity to optimize. We're simulating "noise-free" circuits, even in this case.
(This gives us an opportunity to think about time intervals, but also space between physical qubits, in a relativistic way, and constrained by the light-cone of an event at a qubit physical location.)
Per the PR https://github.com/vm6502q/qrack/pull/870, I have just directly exposed 2x2 complex matrix gates, and their controlled variants, directly through the Qrack PInvoke DLL API. Tomorrow, I will correspondingly update the Qrack plugin for OpenRelativity. Then, I will code common 0-to-1-root gates in C# in the Qrack plugin for OpenRelativity, with particular focus on roots of Clifford group gates, but ultimately offering universal gate roots.
Single bit gates would take advantage of stabilizer "hybridization" in Qrack, but controlled gates will only do so if they are "phase" or "inversion," which controlled Pauli gate roots will not generally be. These controlled gate might pose an opportunity for optimization, in Qrack, but we probably won't worry about this at first, as we'll start with relatively small simulations in OpenRelativity.
This morning, I've update the plugin DLL, as I've said. I have also added a PowX()
convenience wrapper, over the new DLL method. PowX()
applies arbitrary powers/roots of the Pauli X gate.
I will continue adding convenience wrappers sufficient to support a finite difference time evolution variant of some Qrack benchmark suite unit, probably test_stabilizer_ct_nn
.
We might require that multi-qubit coupler gates take longer to complete than the transit time of light between coupled qubit positions, but this doesn't really impose a satisfying causality constraint, when an instantaneous root of a gate per step is still a gate in itself. It might not even be necessary to think of the couplers this way, as they ostensibly have spatial extent and operate on both qubits in potential space-like separation, (leaving aside a philosophical discussion of causality in the context of entanglement, but I'm not trying to impose new physical constraints against our knowledge of Bell's inequalities).
I think I'm diverting back to Qrack internal development, for a day or a few, to optimize for the case of this issue.
See https://github.com/vm6502q/qrack/issues/871.
However, with the latest plugin update, here in OpenRelativity, continuously linearly time-evolved gates are already easily done, for Clifford group, as well as a fairly round universal set of gates.
On second thought, for that issue in Qrack, the QFusion
layer is going to require a lot of work, that I can't complete this weekend. I want to experiment with the concept in this issue first, in OpenRelativity.
I'll update the plugin with the latest DLL changes, from yesterday, which will also give significant performance advantages. Even with a clean and complete QFusion
refactor, if probability is being queried every FixedUpdate()
frame, to give meaningful visual feedback to the user about quantum state, no performance gains might be realized, yet.
Every detected issue with the Qrack plugin was sorted, and I just added a scene that simulates an idealized IBM Q Yorktown topology, running a random circuit!
We have scenes with elementary demonstrations of Qrack quantum computer simulator plugin capabilities, interfacing with relativistic physics. (If only out of shear boredom,) I want to adapt the concepts used in Qrack library benchmarks, like "chip-like" nearest-neighbor coupler simulations, to evolve through relativistic space-time, under the influence of gravity.
More details will follow, as I think about it, this weekend.