Enhancing Tesseract Decoder Support For Scalable Quantum Observables

Hey guys! Let's dive into an exciting discussion about enhancing the Tesseract decoder. Currently, Tesseract has a limitation: it only supports up to 32 logical observables when decoding directly to logical observables. This can be a bit of a bottleneck, especially when dealing with more complex quantum error correction codes. So, let's explore this issue and discuss potential solutions to make Tesseract even more powerful.

The Current Limitation

As it stands, the Tesseract decoder in its current form has a cap of 32 logical observables. This means that if you're working with a quantum system that requires more than 32 observables, you might run into some limitations. Let's take a look at a practical example using the Python wrapper to illustrate this issue.

Here’s a snippet of code that demonstrates the problem:

import stim
from tesseract_decoder import tesseract

for i in (0, 1, 30, 31, 32, 33):
    dem = stim.DetectorErrorModel(f'''
        error(0.01) D0 L{i}
    ''')

    config = tesseract.TesseractConfig(dem)
    decoder = tesseract.TesseractDecoder(config)
    prediction = decoder.decode(detections=[0])
    print(f"i={i}, prediction={prediction}")

When you run this code, you'll notice that the output silently fails for more than 32 observables. It’s kind of like trying to fit a square peg in a round hole – it just doesn’t quite work. The output looks something like this:

i=0, prediction=1
i=1, prediction=2
i=30, prediction=1073741824
i=31, prediction=18446744071562067968
i=32, prediction=1
i=33, prediction=2

See how the predictions become a bit wonky after i=31? That’s the limitation kicking in. This behavior isn't ideal, and it's a clear sign that we need a more robust solution for handling a larger number of observables. The key takeaway here is that the current implementation silently fails when the number of observables exceeds 32, which can lead to unexpected results and headaches for users. We need a fix that gracefully handles any number of observables, ensuring accurate decoding regardless of the complexity of the quantum system.

The Desired Enhancement

Ideally, we want Tesseract to support any number of observables without breaking a sweat. Imagine being able to decode systems with hundreds or even thousands of observables – that's the dream! One way to achieve this is by modifying the return type of the tesseract.TesseractDecoder.decode function. Instead of returning an integer-type mask, we could make it more closely match the return type of the obs array from stim.CompiledDetectorSampler.sample. This would provide a more intuitive and flexible interface for users.

Currently, stim.CompiledDetectorSampler.sample returns an obs array in the following format:

        if separate_observables=True and bit_packed=False:
            A (dets, obs) tuple.
            dets.dtype=bool_
            dets.shape=(shots, num_detectors)
            obs.dtype=bool_
            obs.shape=(shots, num_observables)
            The bit for detection event `m` in shot `s` is at
                dets[s, m]
            The bit for observable `m` in shot `s` is at
                obs[s, m]

So, for a single shot, tesseract.TesseractDecoder.decode could return a numpy.array with a bool dtype and a shape of (num_observables,). This array would indicate which observables are flipped (obs[m]==True) and which are not (obs[m]==False). This approach aligns well with how Stim handles observables and would make Tesseract more consistent and user-friendly. By adopting this return type, users can easily interpret the results and integrate them into their workflows without needing to perform manual conversions or bit manipulations. This consistency not only simplifies the user experience but also reduces the potential for errors in downstream processing.

Internal Storage Optimization

While returning a numpy.array is great for the Python interface, under the hood, it might be more efficient to store the indices of flipped observables for each symptom. Think about it: in many cases, the number of flipped observables is relatively small compared to the total number of observables. Storing a dense array of booleans might waste memory, especially when dealing with a large number of observables. A more memory-efficient approach is to store only the indices of the flipped observables.

Consider the current definition of the Symptom struct in Tesseract:

struct Symptom {
  std::vector<int> detectors;
  ObservablesMask observables;
...

We could change this to:

struct Symptom {
  std::vector<int> detectors;
  std::vector<int> observables;
...

Instead of using an ObservablesMask, which likely uses a bitset or similar structure to represent the flipped observables, we use a std::vector<int> to store the indices of the flipped observables. This change could lead to significant memory savings, especially for large-scale simulations. By switching to a vector of integers, we can drastically reduce memory consumption, particularly in scenarios where only a small subset of observables are flipped. This optimization is crucial for handling larger and more complex quantum error correction codes, ensuring that Tesseract remains scalable and efficient.

Benefits of the Proposed Changes

Implementing these changes would bring several benefits to Tesseract and its users. First and foremost, it would remove the artificial limit of 32 observables, allowing Tesseract to handle a much wider range of quantum error correction codes. This increased flexibility would make Tesseract a more versatile tool for quantum computing research and development. By removing this limitation, Tesseract can be applied to a broader range of quantum systems and error correction schemes, making it a more versatile tool for researchers and developers. This expanded applicability is crucial for pushing the boundaries of quantum computing and exploring novel error correction techniques.

Secondly, the proposed changes would improve the usability of Tesseract, particularly in the Python wrapper. Returning a numpy.array that aligns with Stim's obs array would make it easier for users to integrate Tesseract into their existing workflows. No more wrestling with bit masks or manual conversions – just clean, intuitive data structures. The consistency with Stim's data structures simplifies integration and reduces the learning curve for new users. This ease of use is essential for fostering adoption and collaboration within the quantum computing community.

Finally, the internal storage optimization would make Tesseract more memory-efficient, allowing it to handle larger and more complex simulations. This is crucial for scaling up quantum error correction and exploring fault-tolerant quantum computing. By optimizing memory usage, Tesseract can tackle larger and more intricate error correction problems, paving the way for fault-tolerant quantum computers. This scalability is a key requirement for realizing the full potential of quantum computation.

In Summary

Enhancing Tesseract to support over 32 observables is a significant step forward in making it a more powerful and versatile tool for quantum error correction. By modifying the return type of tesseract.TesseractDecoder.decode and optimizing the internal storage of observables, we can unlock new possibilities for Tesseract and its users. So, what do you guys think? Are you excited about these potential improvements? Let's discuss and make Tesseract even better!