E.g. the file

error(0.1) D0 D2

Implies a detector D1 exists, but no error mechanism affects it.

I don't see any way to append a CircuitInstruction directly to a Circuit (working in the Python interface)

Use case: I want to separate out the code for the noiseless QEC circuit from the noise. So I write the noiseless version. Then I want to be able to iterate over the circuit and create a new circuit by appending the previous instructions plus new ones for noise (and dealing appropriately with repeat blocks).

When trying to compile on mac, I get the following error:

[ 24%] Building CXX object CMakeFiles/stim_benchmark.dir/src/simulators/measure_record_batch_writer.cc.o
In file included from /Users/mgnewman/miscellaneous/Stim/src/simulators/measure_record_batch_writer.cc:17:
In file included from /Users/mgnewman/miscellaneous/Stim/src/simulators/measure_record_batch_writer.h:20:
In file included from /Users/mgnewman/miscellaneous/Stim/src/simulators/../simd/simd_bit_table.h:20:
In file included from /Users/mgnewman/miscellaneous/Stim/src/simulators/../simd/simd_bits.h:21:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:1641:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:643:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2338:5: error:
delete called on 'MeasureRecordWriter' that is abstract but has
non-virtual destructor [-Werror,-Wdelete-abstract-non-virtual-dtor]
delete __ptr;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2651:7: note:
in instantiation of member function
'std::__1::default_delete::operator()' requested here
_ptr.second()(__tmp);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2605:19: note:
in instantiation of member function
'std::__1::unique_ptr<MeasureRecordWriter,
std::__1::default_delete >::reset' requested here
~unique_ptr() { reset(); }
^
/Users/mgnewman/miscellaneous/Stim/src/simulators/measure_record_batch_writer.cc:33:27: note:
in instantiation of member function
'std::__1::unique_ptr<MeasureRecordWriter,
std::__1::default_delete >::~unique_ptr' requested
here
writers.push_back(MeasureRecordWriter::make(out, f));
^
1 error generated.
make[2]: *** [CMakeFiles/stim_benchmark.dir/src/simulators/measure_record_batch_writer.cc.o] Error 1
make[1]: *** [CMakeFiles/stim_benchmark.dir/all] Error 2
make: *** [all] Error 2

Maybe just an argument to the measurement operation is a probability of flipping the result? Or else specialized MX_NOISY operations.

First of all, thank you for creating this, it is incredibly useful!!! Not the least as a reference for other code writers!

I am the developer of QuantumClifford.jl, which implements some useful Clifford circuit tools. It does not have the elegant Pauli frame tracking that enables your ridiculously high speeds, and generally, it has not been hand-tuned, but it is fairly fast and it has its uses elsewhere ;)

I made some recent improvements in the inner-loop methods (the Pauli multiplication method) that were inspired by your work and wanted to see how it compares against stim. I was surprised that in one (very restricted) micro-benchmark the pure julia code was faster than your C++ SIMD code.

Here is the example:

julia> using QuantumClifford, BenchmarkTools
julia> a = random_pauli(1_000_000);
julia> b = random_pauli(1_000_000);
julia> @btime a*b;
  41.598 μs (4 allocations: 244.39 KiB)

julia> b = random_pauli(1_000_000_000);
julia> a = random_pauli(1_000_000_000);
julia> @btime a*b;
  101.032 ms (4 allocations: 238.42 MiB)

In [2]: from stim import *
In [3]: a = PauliString.random(1_000_000);
In [4]: b = PauliString.random(1_000_000);
In [5]: %timeit a*b
42.7 µs ± 17.8 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

In [6]: b = PauliString.random(1_000_000_000);
In [7]: a = PauliString.random(1_000_000_000);
In [8]: %timeit a*b
214 ms ± 4.65 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

The results are basically the same, except for larger (really large) Pauli's, julia is faster by a factor of 2ish. I do not know whether this is just some slowdown caused by the python interface. Or it might be due to the version of gcc/llvm that was used to compile stim.

Just to be clear, I am not claiming that my julia library is generally faster: its aim is somewhat different from the aim of Stim and I am certain that, holistically, Stim blows everyone out of the water for the task for which it was designed. But given how crazy fast Stim is, I assumed that you would want to know that there might be still some more optimizations to be done. I can try to dig up the machine code that julia compiles if that would be of use. Here is the julia code performing this operation, which is fairly similar to your C++ code.

Currently the only way to get the integer value is to parse the str!

Being able to get it into a file without going through python is much faster and sometimes useful

Method should take a SampleFormat, a FILE *, a max_shots (must be a multiple of 64) or similar, an expected_bits_per_shot, and return a simd_bit_table.

enum SampleFormat {
    /// Human readable format.
    ///
    /// For each shot:
    ///     For each measurement:
    ///         Output '0' if false, '1' if true
    ///     Output '\n'
    SAMPLE_FORMAT_01,

    /// Binary format.
    ///
    /// For each shot:
    ///     For each group of 8 measurement (padded with 0s if needed):
    ///         Output a bit packed byte (least significant bit of byte has first measurement)
    SAMPLE_FORMAT_B8,

    /// Transposed binary format.
    ///
    /// For each measurement:
    ///     For each group of 64 shots (padded with 0s if needed):
    ///         Output bit packed bytes (least significant bit of first byte has first shot)
    SAMPLE_FORMAT_PTB64,

    /// Human readable compressed format.
    ///
    /// For each shot:
    ///     For each measurement_index where the measurement result was 1:
    ///         Output decimal(measurement_index)
    SAMPLE_FORMAT_HITS,

    /// Binary run-length format.
    ///
    /// For each shot:
    ///     Append a one to the shot
    ///     For each run length d of zeros between ones (including runs of length 0):
    ///         Output [0x255] * (d // 255) + [d % 255]
    SAMPLE_FORMAT_R8,

    /// Specific to detection event data.
    ///
    /// For each shot:
    ///     Output "shot" + " D#" for each detector that fired + " L#" for each observable that was inverted + "\n".
    SAMPLE_FORMAT_DETS,
};

Currently, PAULI_CHANNEL_2 is 10x slower than DEPOLARIZE2.

An idea to try is, if the operation is applied to enough targets, create an alias sampling table for the probability distribution over the non-identity part of the channel. Then use rare-error sampling to decide which qubits to apply the alias sampling to.

The X distance of a repetition code generated with stim.Circuit.generated is off by 1 (inputting distance d generates a distance d+1 repetition code).

E.g. rather than getting 2d-1 qubits I get:

>>> import stim
>>> stim.Circuit.generated("repetition_code:memory", distance=3, rounds=1).num_qubits
7
>>> stim.Circuit.generated("repetition_code:memory", distance=5, rounds=1).num_qubits
11

Looks like it could be fixed by subtracting one here.

When I am running a large number of samples simulations simultaneously using stim in a massively multi-process environment (python not supporting multi-threading, I use multi-process computation using python multithreading starmap), this happens semi-randomly when I run a multi-threaded simulation, see the stack trace below:

This seems to be related to a multi-threading bug in libstdc++, so perhaps using the approach used by the google cloud c++ api would be a good approach. See:

googleapis/google-cloud-cpp-common#208

googleapis/google-cloud-cpp-common#272

seeing as the call to random_device is only done once per process in PYBIND_SHARED_RNG(), it is probably safe performance-wise to use the second fix, as the performance regression should be very minor.

This seems to be related to the shared rdseed buffer in certain Intel cpus.

• stim.Tableau.x_output_pauli(out, in)
• stim.Tableau.z_output_pauli(out, in)
• stim.Tableau.inverse_x_output_pauli(out, in)
• stim.Tableau.inverse_z_output_pauli(out, in)
• stim.Tableau.inverse_x_output(out, unsigned: bool = false)
• stim.Tableau.inverse_z_output(out, unsigned: bool = false)
• stim.Tableau.inverse(unsigned: bool = false)

    auto r = FrameSimulator::sample_flipped_measurements(Circuit(R"CIRCUIT(
        RY 0
        MY 0
        MY 0
        Z_ERROR(1) 0
        MY 0
        MY 0
        Z_ERROR(1) 0
        MY 0
        MY 0
    )CIRCUIT"), 10000, SHARED_TEST_RNG());
    ASSERT_EQ(r[0].popcnt(), 0);
    ASSERT_EQ(r[1].popcnt(), 0);
    ASSERT_EQ(r[2].popcnt(), 10000);
    ASSERT_EQ(r[3].popcnt(), 10000);
    ASSERT_EQ(r[4].popcnt(), 0);
    ASSERT_EQ(r[5].popcnt(), 0);

fails

Install the stim package as required and import it. But it cannot run properly on PyCharm. The result is "ImportError: PauliString: PyType_Ready failed (UnicodeDecodeError: 'utf-8' codec can't decode bytes in position 46-47: invalid continuation byte)!"

Similar to TFQ, Stim could benefit from knowing about breaking changes earlier rather than later coming from Cirq.

E.g. circuit[:5] should be a circuit containing the first 5 instructions (or blocks).

Use PauliString slicing code as a reference.

Many simulators typically group noisy channels as pairs (unitary, error channel). When translating this into Stim, it can cause a significant blowup in the representation of the circuit (e.g. requiring a new line for each noisy gate). It would be a nice feature if Stim had a function that could automate the compression of such a circuit into an equivalent representation that minimized the number of lines.

And give good feedback about which error it is in the circuit.

For some simulation experiments, it would be handy to be able to track both the X and Z logical observables without having to set up an EPR pair on the side. These Pauli targets could be used to artificially adjust the simulated observable. They would of course be totally incompatible with physical experiments (you can't do the conversion from measurements to detection events).

Example:

OBSERVABLE_INCLUDE(0) X1 X2 X3
OBSERVABLE_INCLUDE(1) Z1 Z2 Z3
DEPOLARIZE1(0.001) 0 1 2
H 0 1 2
DEPOLARIZE2(0.001) 0 1
CNOT 0 1
CNOT 1 0
CNOT 0 1
H 0 1 2
OBSERVABLE_INCLUDE(0) X1 X2 X3
OBSERVABLE_INCLUDE(1) Z1 Z2 Z3

It's a bit tedious to have to do the repeat blocks and coordinate tracking when consuming the model. Make it easier.

This might fix the undefined behavior sword dangling over the head of a bunch of the simd_bits code.

When building on a mac, I receive the following warnings:

stim-src/src/stabilizers/pauli_string.test.cc:201:9: error: moving a temporary object
      prevents copy elision [-Werror,-Wpessimizing-move]
    x = std::move(PauliString::from_str("XXY"));
        ^
stim-src/src/stabilizers/pauli_string.test.cc:201:9: note: remove std::move call here
    x = std::move(PauliString::from_str("XXY"));
        ^~~~~~~~~~                            ~
stim-src/src/stabilizers/pauli_string.test.cc:203:9: error: moving a temporary object
      prevents copy elision [-Werror,-Wpessimizing-move]
    x = std::move(PauliString::from_str("-IIX"));
        ^
stim-src/src/stabilizers/pauli_string.test.cc:203:9: note: remove std::move call here
    x = std::move(PauliString::from_str("-IIX"));
        ^~~~~~~~~~                             ~
2 errors generated.