Collecting interface definition

[david-pl]

The general plan for this package is to be a lightweight dependency that defines the interface for a number of different packages such that they can all work together without clashing. The list of packages includes (at least) the following:

• QuantumOpticsBase.jl
• QuantumCumulants.jl
• QuantumSavory.jl

In this issue I want to collect what actually should be part of the interface package. So far I've only added very few basic function definitions. @krastanov what functionality do we need for QuantumSavory? @amilsted do you have any input here?

Off the top of my head I'm thinking of the following things:

Functions

• tensor / ⊗
• destroy / create and other operator constructors (used in QuantumCumulants)?
• embed
• Common operations on operators (tr, ptrace, expect, dagger, ...)
• State constructors
• What other functions do we need for states? Most of them are functions from LinearAlgebra I think
• Any other functions for bases?

Types

I'm not sure about types as it could easily lead to type-piracy. It might make sense to move out Basis types entirely, however. @amilsted do you see any problems with precompilation / method invalidations? Do Basis types need more abstraction (e.g. adding a label, removing information on dimensions)?

Also pinging @bastikr, @ChristophHotter , @j-moser here.

[Krastanov]

In terms of naming, may we remove the "Optics" part of the name? Many of these functions would be useful for QuantumClifford and I feel it would be a bit confusing to related Optics to Clifford circuits.

If you give me push privilidges I can push a version that already works with experimental branches of QSymbolics, QuantumClifford, and QuantumOpticsBase. No need for any changes to QuantumOptics.

[Krastanov]

For the moment I have not needed any changes to Basis, but it was helpful to introduce Abstract[Ket|Operator|SuperOperator].

[Krastanov]

Type-piracy issues can be detected with static analysis like Aqua

[Krastanov]

Here is the draft package I have been toying with. Basically exactly what you described. Happy to transfer it to qojulia if it seems like a reasonable basis.

https://github.com/Krastanov/QuantumCore.jl

Here is the branch of QuantumOpticsBase that works with it: https://github.com/qojulia/QuantumOpticsBase.jl/pull/73

Here is the branch of QuantumClifford that works with it: https://github.com/Krastanov/QuantumClifford.jl/compare/quantumcore

Here is the newly factored out QSymbolics that shows how this enables some interesting conversions between different formalisms: https://github.com/Krastanov/QSymbolics.jl

Documentation of what is possible with QSymbolics: https://krastanov.github.io/QuantumSavory.jl/dev/symbolics/

A lot of this type of mixing of formalisms is done in the kernel of QuantumSavory: https://krastanov.github.io/QuantumSavory.jl/dev/

The overall relationship I am imagining is

Some observations on which feedback would be helpful:

• Main concepts that I find useful to factor out are
  • functions like tensor and dm and projector
  • abstract types for kets, operators, and superoperators
  • all of the infrastructure behind bases
• I also added some QuantumClifford functions that would be really convenient for me if they are available at some point in QuantumOptics
  • see the should_upstream file https://github.com/Krastanov/QSymbolics.jl/blob/main/src/should_upstream.jl
  • in particular the apply!(ket, indices, operator) function which is roughly embed(..., indices, operator)*ket and lets you apply an operator to a subspace of a ket
  • if the existence of these functions is not too unreasonable, I would like to slowly start submitting pull requests adding the functionality to QuantumOpticsBase
• There are probably plenty of things in QuantumCore that are probably unnecessary (and things not yet included), but because this is just a hidden interface package, we can iterate on it for a while without worrying about breaking anything

Would it make sense to move this package to qojulia soon and publishing it, even in such draft form, so that we can start running the CI on pull requests like the one here: https://github.com/qojulia/QuantumOpticsBase.jl/pull/73

Would it make sense to reach out to https://github.com/JuliaQuantum which seems to be a long dead organization and checking whether they would give us the organization name so we can host all these packages in a single location? I am also happy to host everything under qojulia, it is just the name would be a bit misleading when the other packages are added.

[david-pl]

@Krastanov I've invited you to work on this repository. Alternatively you can also transfer the one you already have (will add you as repository owner afterwards of course), whichever way you prefer is fine by me, thanks. I was actually browsing through your repos before creating this one, I must have missed it, sorry about that.

In terms of naming, may we remove the "Optics" part of the name?

Sure.

Main concepts that I find useful to factor out are

I agree on all of those. Specifically, I think it makes a lot of sense to factor out bases.

see the should_upstream file https://github.com/Krastanov/QSymbolics.jl/blob/main/src/should_upstream.jl

They look like some short-hand convenience functions, so I don't see a problem in moving them upstream.

There are probably plenty of things in QuantumCore that are probably unnecessary (and things not yet included), but because this is just a hidden interface package, we can iterate on it for a while without worrying about breaking anything

Yes, we'll definitely need some iteration and testing before depending on this package with all the libraries. Let's just take it step by step. Still, as you say, that shouldn't keep us from publishing it IMHO.

[Krastanov]

I must have missed it, sorry about that.

No, it was my bad. The repository was not published until a day ago.

I made the pull request #2 which copies over that package.

[Krastanov]

@david-pl , it seems QuantumCore is too close to other package names according to the registration pull request https://github.com/JuliaRegistries/General/pull/73036 (presumably protection against scamming with misspelled package names that proliferated in python and javascript registries)

How about we change the name yet again to QuantumInterface following the example of https://github.com/JuliaArrays/ArrayInterface.jl ?

Or we can ask for a manual merge in the registry?

[david-pl]

@Krastanov QuantumInterface sounds good to me. I'll do the repo, can you do the code?

[Krastanov]

Yes, I will proceed with the cleanup and a new attempt at registration