You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 12, 2024. It is now read-only.
When dumping states from the Sparsesimulator, it converts qubit labels as binary into integers. Which bit is considered the most or least significant changes throughout execution.
To Reproduce
@Test("SparseSimulator")
operation dump() : Unit {
for idLoop in 0..1 {
use qubits = Qubit[4] {
X(qubits[0]);
X(qubits[1]);
X(qubits[3]);
for idx in 0..3 {
Message($"Qubit {idx}: {M(qubits[idx])}");
}
DumpMachine();
ResetAll(qubits);
}
}
}
Expected behavior
DumpMachine() should output |11> in both iterations.
Actual behavior
DumpMachine() outputs |11> in the first iteration but |13> in the second. In fact, repeating more than twice, every odd iteration outputs |11> and every even iteration outputs |13>.
System information
OS: Ubuntu 20.04
.NET Core Version: 6.0
IQ# Version 0.28.302812
Additional context
Using DumpRegister((), qubits) gives the expected behaviour. Thinking about this carefully, Q# doesn't seem to have a global notion of an ordering of the qubits, which would be necessary to expect/enforce an endianness to a machine state dump. So in some sense this is the expected behaviour, since we shouldn't expect an ordering; however, it feels very unexpected at first glance!
While DumpRegister will work for my use case, I can imagine other scenarios where a function does not have access to all qubits currently in the machine but still wants to run diagnostics, and still wants an ordering enforced on the qubits it can see. A clumsy solution might be to allow an array of qubits to be passed as on argument to DumpMachine, and it would put those qubits in that order as the first qubits of the output.
The text was updated successfully, but these errors were encountered:
Describe the bug
When dumping states from the Sparsesimulator, it converts qubit labels as binary into integers. Which bit is considered the most or least significant changes throughout execution.
To Reproduce
Expected behavior
DumpMachine() should output |11> in both iterations.
Actual behavior
DumpMachine() outputs |11> in the first iteration but |13> in the second. In fact, repeating more than twice, every odd iteration outputs |11> and every even iteration outputs |13>.
System information
OS: Ubuntu 20.04
.NET Core Version: 6.0
IQ# Version 0.28.302812
Additional context
Using
DumpRegister((), qubits)
gives the expected behaviour. Thinking about this carefully, Q# doesn't seem to have a global notion of an ordering of the qubits, which would be necessary to expect/enforce an endianness to a machine state dump. So in some sense this is the expected behaviour, since we shouldn't expect an ordering; however, it feels very unexpected at first glance!While DumpRegister will work for my use case, I can imagine other scenarios where a function does not have access to all qubits currently in the machine but still wants to run diagnostics, and still wants an ordering enforced on the qubits it can see. A clumsy solution might be to allow an array of qubits to be passed as on argument to DumpMachine, and it would put those qubits in that order as the first qubits of the output.
The text was updated successfully, but these errors were encountered: