Basis ordering discrepancy between Rigetti and staq

[DevelopDaily]

Here is a simple test case:

OPENQASM 2.0;
include "qelib1.inc";

qreg q[2];
id q[0];
x q[1];

The final state by a qpprun:

>> Final state:
0   1   0   0 

The snippet of the Rigetti Quil code out of the staq:

I 0
X 1

The final state by a Rigettirun:

[
0.+0.j 
0.+0.j 
1.+0.j 
0.+0.j
]

Rigettimakes a very big deal of basis ordering, which is documented here.

I quote the key point:

The WavefunctionSimulator enumerates bitstrings such that qubit 0 is the least significant bit (LSB)...

This convention is counter to that often found in the quantum computing literature where bitstrings are often ordered such that the lowest-index qubit is on the left.

[vsoftco]

I think staq does the right thing in simply translating gate sets. The qubit ordering comes into play only when executing. In other words, the assembly code should be invariant, but execution will depend of course on how those bits are interpreted. I am very much tempted to leave staq as is, and only document the endianness (bit ordering) on the simulator part. That's because Rigetti still numbers qubits as we do, but only "interprets" them differently when writing down the state vector.

So, in other words, I still want

x q[0] // qasm

to be translated to

X 0 // Rigetti

and deal with endianness at the end of processing (i.e., when executing on a simulator). Otherwise, generating code with bits reversed will create a lot of misunderstandings and further issues down the line.

In a nutshell, our system is "Big-endian" (as well as most others in QC), but Rigetti's is "Little-endian". Code is portable up to qubit relabeling at the end. One option is to add an endianness flag to the executor's qpp::QEngine, i.e.

explicit QEngine(const QCircuit& qc, bool big_endian = true)

[DevelopDaily]

Agreed. Well-thought-out. As long as it is a conscious design decision and well documented, that should be good enough.

Or, if possible, a utility standalone function to prepare/interpret endianness would be nice, leaving the critical QEngine intact. If impossible, the current code can be kept as it is.

[vsoftco]

@DevelopDaily Good point, will think about it. I'll refer this to https://github.com/softwareQinc/qpp/issues/104, as they are closely related. I think this should be closed for staq, and kept open for qpp.

[DevelopDaily]

Great. Thanks.