Making an AbstractQuantumBase.jl package or something like that

[Krastanov]

I have some libraries that work with stabilizer states and noisy stabilizer circuits.

Slowly, I have started working on functions like entropy and entanglement_of_creation and is_factorizable, etc. Some such functions exist in QuantumOptics and I would like to simply create methods for them so that the code can have easier time inter-operating. One cool example would be doing some entanglement purification with stabilizer states and then doing a tensor product of a stabilizer state (represented as a tableaux) and a Ket from QuantumOptics. In principle this should be trivial, but I does not make sense for QuantumOptics to import QuantumClifford or vice-versa.

Hence, should we try to start discussing a common base, just so it is easy for people to have interoperable code? QuantumOpticsBase is not appropriate for this because (a) it has deep assumptions about treating things as qudits and vectors in Hilbert spaces (b) it has a ton of non-abstract implementations that ideally will not be in a package that simply defines interfaces (c) interesting functions that QuantumClifford would want to overload are actually definited in QuantumOptics, not QuantumOpticsBase

Here is an example list of things I would like to have as common interfaces: entropy, purity, tensor, entanglement_of_formation, entanglement_of_distillation, hashing_entanglement_yield, relative_entropy, entanglement_of_assistance, entanglement_robustness, magic_robustness, trace_distance, quantum_fisher_information, helstrom_metric, wigner.

What would be a good way to get such a common interface?

[Krastanov]

Also, the same way the efficient to simulate Stabilizer methods have implementations very different from what is in QuantumOptics, one can have the same for Gaussian circuit.

[david-pl]

I would be open to this in principle, but let's discuss first to make sure it really makes sense to do something like that.

What would be a good way to get such a common interface?

Your list contains only functions. So taking abstraction to the extreme, we could really just make a package that contains a bunch of empty function definitions, e.g. function entropy end.

Which types make sense to have would be another question. You mention defining some tensor product, so abstract types such as StateVector would be needed there. I guess we'd really need to define a new proper interface for things such as states to ensure the same assumptions hold everywhere. So getting the type hierarchy right will be the difficult part here.

[Krastanov]

I am actually much more interested in defining interfaces (i.e. function entropy end) than worrying about abstract types. Abstract types would certainly be great to have, but I feel that can wait (or just be completely unnecessary given that most of the abstract julia infrastructure is moving to traits, not common abstract types).

I think this is a good example of such abstract base library: https://github.com/JuliaArrays/ArrayInterface.jl

Maybe we can start a collaborative document on which we can list what functions are expected (both in terms of traits like ishermitian and in terms of useful physics like partial_trace and entropy)?

I suspect the first version of the base library would indeed just be a list of function names and nothing else. But it would be great if partial traces in QuantumClifford just use the partial trace function used in QuantumOptics.

[Krastanov]

@david-pl , as I am trying to prototype this, I have a few more questions on how to implement an interface for a quantum object that matches the semantics of QO.jl while having drastically different internals.

Say I have an object containing a tableau of 2 qubits, for instance this mixed state tableau:

ZZ

The density matrix corresponding to that tableau is |0⟩⟨0|+|1⟩⟨1|. My questions are:

• What would be the most idiomatic QO.jl method to overload in order use it for converting the tableau into a QO.jl density matrix? Something that naturally uses the Julia convert&co facilities so that a simple thing like QuantumOptics.Operator * QuantumClifford.Stabilizer is a possible operation.
• Currently QO.jl does not use traits, rather it uses only (parameterized) types. How do you feel about abstracting some of these types away or creating traits (e.g. SimpleTraits.jl) so that software that uses other representations (e.g. Gaussian Quantum Computing or Stabilizer Tableau States or Tensor Product States) can fit in the hierarchy you already have? Obviously all of this can be implemented from scratch, but it would be silly to do it for the 5th time in Julia, when QO.jl is already implementing something like 25% of the necessary types/traits.

The reason for these questions is that the MIT quantum photonics group is now developing a hardware simulator in the style of SPICE and Verilog, but for quantum hardware, and this type of interoperability is becoming important.

[david-pl]

• I'd say the most QO.jl thing to do is to implement a method for DenseOperator(::Stabilizer), but that'd still require implementation of the * method matching the types. There's no fallback that uses Julia's conversion so it won't "just work".
• I'm not very familiar with traits, but it seems to me that traits could be quite useful for QuantumOptics.jl stuff. Operators in QO.jl sit in kind of a weird place between being represented by AbstractArray (when the .data field is a matrix) or not (e.g. FFTOperator and lazy operators). So that might actually be a good solution to have in general. Again though, I'm not too familiar with traits so I'm not sure.

In general I have to say I have some doubts as to whether this interoperability is too much of a stretch for QuantumOptics. It's difficult to tell though as my expertise in quantum hardware is quite limited.

[Krastanov]

I have been implementing much of that interoperability in a separate piece of code, mostly just ensuring that the appropriate methods exist when types are mixed together from the two packages. And it should also work with a package for gaussian states too. The main issue is the namespacing of the different functions. * is fine because it is in base. ptrace not so much because to make it work in QuantumClifford currently, QuantumOptics needs to be made a dependency, which is a bit silly.

When I have it fully working, maybe we can meet and discuss whether a minimal "interface" package can be created? (it is a part of some research code that is my actual focus, so factoring it out in a way that is community friendly is not my main priority right now)

[david-pl]

Having a starting point, i.e. the "glue" code you mention, would be useful to continue this discussion. It would be great if you could share it once it's finished, or at least in a working state.

[Krastanov]

I am setting it up now. Any preferences on package name:

• AbstractQuantum
• QuantumCore
• QuantumBase
• or any combination of [Abstract]Quantum[Core|Base]

Unless there are preferences, I will just pick one and publish the package later this week.

[david-pl]

@Krastanov as the plan would be for most qojulia packages to depend on the abstract one, I'd really like this core package to be part of the qojulia organization. Would that be okay with you?

[Krastanov]

Yes, that makes total sense!

[david-pl]

@Krastanov I've created a package here and another issue to collect what we actually need to be part of the interface there: qojulia/QuantumInterface.jl#1
Looking forward to your input!

[Krastanov]

closing now that we rely on https://github.com/qojulia/QuantumInterface.jl