-
Notifications
You must be signed in to change notification settings - Fork 66
Description
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:
SimpleTraits.jl. Used byGraphs.jl.RequiredInterfaces.jlInterfaces.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
QuantumInterfacebeing 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.jlwhich 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
Labels
Type
Projects
Status