Bit order: State Vector Results Inconsistent with Other Simulators

[simplygreatwork]

Hi Stewart,

I love your work. Happy anniversary for Q.js!

When run XHHH in your live editor, the results make sense to me. But the results you give are inconsistent with results of other simulators such as https://quantum-circuit.com/ and http://oreilly-qc.github.io/ Results from your live editor are grouped - yet results from the other simulators are interspersed.

Can you explain why these results are so inconsistent? Another library which returns results similar to yours for this example is https://github.com/adamisntdead/qics

[simplygreatwork]

I think the issue is that some simulators display the state vectors in high qubit to low qubit order and some in low qubit to high qubit order. I prefer the order that you list the results but it's not consistent with a lot of the pervasive simulators. It just makes sense to me to list the elements of each result braket in the same order as the circuit was configured - like you do.

[stewdio]

Hi Philip 👋

I think I see what you’re saying, but let me be sure. I used Q’s Playground page to input this:

X H H H

That created a circuit that was 4 moments long, operating on a single qubit. Here’s a screen grab of the resulting interactive circuit diagram and probability results:

If I’m understanding you correctly, the issue is that Probability Results are being listed with 0 first, then 1 second, yes? And just to double check—using an even simpler coin-flip example illustrates the same issue, yes? Just a single H operation would also yield:

1  |0⟩  ██████████░░░░░░░░░░  50% chance
2  |1⟩  ██████████░░░░░░░░░░  50% chance

So you’re saying the order of the results list ought to be reversed like this?

1  |1⟩  ██████████░░░░░░░░░░  50% chance
2  |0⟩  ██████████░░░░░░░░░░  50% chance

Or to use a slightly more complex example, this:

H
H

ought to result in this listing?

1  |11⟩  █████░░░░░░░░░░░░░░░  25% chance
2  |10⟩  █████░░░░░░░░░░░░░░░  25% chance
3  |01⟩  █████░░░░░░░░░░░░░░░  25% chance
4  |00⟩  █████░░░░░░░░░░░░░░░  25% chance

[simplygreatwork]

Much apology. I wasn't clear. I intended four qubits with one instructions per qubit.

X
H
H
H

Some other simulators seem to list the order of probability in the order of Q4, Q3, Q2, then Q1

1 |0000> 0.00%
2 |0001> 12.50%
3 |0010> 0.00%
4 |0011> 12.50%
5 |0100> 0.00%
6 |0101> 12.50%
7 |0110> 0.00%
8 |0111> 12.50%
9 |1000> 0.00%
10 |1001> 12.50%
11 |1010> 0.00%
12 |1011> 12.50%
13 |1100> 0.00%
14 |1101> 12.50%
15 |1110> 0.00%
16 |1111> 12.50%

Also an example at: https://quantum-circuit.com/home/simulate/mgbpRHGLJS3BpKMdS/browser

However, the ordering which you use makes the most sense to me.

[jag-p]

Hi,

As a convention, in quantum circuits, qubit 0 is the least significant bit.

Say you want to output as 5 ( binary 101 ). I should be able to set
qubit0 to X
qubit1 to I
qubit2 to X
and rest of qubits to I to get my result - irrespective of number of qubits.

in Q.js currently - value of qubit0 depends on total number of qubits present, as it is considered most significant bit. Can potentially cause issues when dynamically building and appending circuits.

For eg. Results for both these should be binary 5 - irrespective of number of qubits in the circuit

1. 3-qubit circuit

X
I
X
==== 
|101> 100%

2. 5-qubit circuit

X
I
X
I
I
===
|00101> 100%  ( not |10100> ) 

[marwahaha]

I'm a casual user, but "display the circuit upside down from the bit order" has always felt confusing to me. I like the way Q.js does it

[stewdio]

👋 Hi, everyone! My apologies for radio silence on this repo for a span. Aside from the pandemic, work, and home life, I also put out a fan-made music “video” made of HTML elements for Thom Yorke’s “Black Swan”, a hand-pose recorder / recognizer for the WebXR API as used on Oculus Quest that interprets ASL finger spelling, a Web Audio guitar pedal of sorts, and other bits that are still in the works. It’s been a lot!

@marwahaha, I have totally agreed with your view of this from the beginning—hence how I implemented the bit order in Q.js. However—and this is a big “however”—@simplygreatwork and @jag-p have opened my eyes to an interesting wrinkle (which @jag-p already described above better than I could) which amounts to this: adding a new register to your already designed circuit totally borks your output because instead of adding a binary digit to the beginning of your output string (which leaves your previous output values as they were), you’re adding it to the end (which shifts all your previous values over by 2ⁿ).

Let’s take a look at a simple example, a one-register, one-moment circuit with a single Hadamard gate:

         m1  
        ┌───┐
r1  |0⟩─┤ H │
        └───┘

A one-register circuit has two possible outcomes, 1 or 2 and our Hadamard gate ensures an equal probability of either outcome.

1  |0⟩  ██████████░░░░░░░░░░  50% chance
2  |1⟩  ██████████░░░░░░░░░░  50% chance

We can write some logic to handle either outcome like so:

if result is 1 then A
if result is 2 then B

Great. All’s well in Q land. But what happens if in the course of sketching out a circuit we simply add an empty register? Let’s do that—add a register and put no operation on it; it’s just a placeholder Identity gate:

         m1  
        ┌───┐
r1  |0⟩─┤ H │
        └───┘
             
r2  |0⟩───○  

Now we have a problem. Our intuition says we’ve changed nothing meaningful about our circuit. Yet because of the bit order that I’ve implemented we’ve accidentally changed our circuit significantly:

1  |00⟩  ██████████░░░░░░░░░░  50% chance
2  |01⟩  ░░░░░░░░░░░░░░░░░░░░   0% chance
3  |10⟩  ██████████░░░░░░░░░░  50% chance
4  |11⟩  ░░░░░░░░░░░░░░░░░░░░   0% chance

We now must re-write our above logic like so:

if result is 1 then A
if result is 3 then B

And this gets worse as we add more registers—even though they are empty.

         m1  
        ┌───┐
r1  |0⟩─┤ H │
        └───┘
             
r2  |0⟩───○  
             
             
r3  |0⟩───○  
             

1  |000⟩  ██████████░░░░░░░░░░  50% chance
2  |001⟩  ░░░░░░░░░░░░░░░░░░░░   0% chance
3  |010⟩  ░░░░░░░░░░░░░░░░░░░░   0% chance
4  |011⟩  ░░░░░░░░░░░░░░░░░░░░   0% chance
5  |100⟩  ██████████░░░░░░░░░░  50% chance
6  |101⟩  ░░░░░░░░░░░░░░░░░░░░   0% chance
7  |110⟩  ░░░░░░░░░░░░░░░░░░░░   0% chance
8  |111⟩  ░░░░░░░░░░░░░░░░░░░░   0% chance

So I’m now in the camp of wanting to reverse Q’s bit order to fall inline with other quantum libraries; now that I better understand why they were implemented that way. (I don’t have a time table for that right now, but it does seem like the right long-term decision.) What say the community?