Skip to content

Investigate interface definition for simulation backend #509

@LEXUGE

Description

@LEXUGE

Goal

The goal of having a "formal" interface definition is to reuse non-simulator specific codes (e.g. benchmarks and testing). Specifically, stabilizer and graph state simulator will both implement an interface like AbstractSimulator.

Another use case of interface would be in graph state simulator itself, where we want to be graph backend agnostic. To that end we might want to setup an interface for different graph libraries so that they become plugable.

Possible Options

I have compared several packages that provide interface-like experience:

  1. SimpleTraits.jl. Used by Graphs.jl.
  2. RequiredInterfaces.jl
  3. Interfaces.jl

Both 2 & 3 doesn't support multiple interface implementation (i.e. a type Foo cannot both implement interfaces I1 and I2). However, I think it's not gonna be a issue for us as our use case is sufficiently simple. And I don't think there will be much reusable code between stabilizer and graph state simulator. And then the advantage of using 2 or 3 is that it enforces the interface to make sure we aren't drifting away accidentally, and makes implementing other interfaces easy.

1 supports dispatching on trait mainly. However, this is not really a use case for us I believe, because I can't think of cases where we want to write like

@traitfn f(x::X,y::Y) where {X,Y; BelongTogether{X,Y}} = "$x and $y forever!"

which SimpleTraits.jl supports.

Current Thoughts

So I think 2 & 3 should be simple to use and good enough for us. Out of 2 & 3, my current preference would be RequiredInterface which appears to be more ergonomic (supports multiple argument on required methods cleanly).

Implementation Plan

The current plan would be define/refine the interface as we develop the graph state simulator. And once agreed the interface is polished enough, we could refactor the stabilizer simulator code to implement the interface as well. And refactor some other simulation-agnostic codes.

This issue should close once we have a "preliminary" simulator interface working.

Further Comments/Questions

  • I have seen QuantumInterface being used in the codebase. However, that package doesn't seen to have any testing/checking provided? In the long run should our interface design be integrated into that package?

  • Another package to watch out is MultipleInterfaces.jl which is yet to be announced in JuliaCon 2025. If it is actually as good as it's advertised, then it should be quite versatile and fit all purposes we might need in the future as codebase grows.

  • I am still busy with exam at the moment. But should be available after June 20!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    In Progress

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions