QBase.jl v0.2.0 Release

Specific Domains Quantum
1

Hi Everyone,

I’m excited to introduce QBase.jl as a base library for quantum information. The goal of QBase.jl is to provide a lightweight computational framework for quantum mechanics. This Julia package provides:

  1. Validated types for quantum states, measurements, and operations.
  2. A catalog of constructors for quantum types.
  3. A basic toolkit for quantum mechanics.

This package is meant to serve the Julia quantum community. If you have ideas for how to improve it, I am happy to accept feedback or contributions. Please visit the QBase.jl repository on github to get involved.

4 Likes
2

Hi there!

Cool package, glad to see more people getting into QM :wink:

A question on the basics, namely quantum states: after a quick glance it seems that your implementations are quite similar to the ones defined over in QuantumOpticsBase.jl (minus the concept of basis choice). On the other hand, we don’t support measurements and stuff like that. Do you think it might make sense to work on a common basis here?

For reference, there’s also QuantumInformation.jl which has some functionality that also appears to be similar to your work, but again I’m not sure.

3

Indeed, those two packages have many similarities with QBase.jl. There is also the https://github.com/JuliaQuantum github group, but it looks pretty dead to me :cry:. My take on the general quantum community in Julia is that it lacks overall cohesion; it’s just a bunch of people writing Julia code for their own quantum projects. My point, however, is that Julia would benefit from an ecosystem of integratable tools for quantum applications. This requires collaboration and cohesion across packages in the Julia Quantum problem space which is simply, the joy of open-source software.

My outlook on the Julia quantum problem space and the role QBase.jl plays in it goes like so. QBase.jl defines the basic types, operations, and algebra over which those types can be manipulated. External packages would then use QBase.jl to provide more advanced functionality. The simple point is, we don’t need 4+ packages defining a type for quantum states. If these packages all agree on a set of core data structures, then those structures can be passed from one package to another. This smooths out the integrations between packages and facilitates the growth of a Julia Quantum ecosystem.

To answer your question, I think working together on the shared problems makes for the best solutions. And as a result, the Julia community will benefit. If you want to get involved, or know someone who might, please reach out to me at brian.d.doolittle@gmail.com. Open-source collaboration is literally what I’m here for.

4

I agree with what you’re saying. That’s actually why I replied to your original post. Since the basic types you mention are already implemented in QuantumOpticsBase (granted in a slightly different way) I was wondering why you chose to write another package defining them again instead of building on top of the ones in QuantumOpticsBase. Basically, as you said

So why write another package defining them? :sweat_smile:

5

There are 2 main reasons why I developed another package:

  1. I wasn’t aware of QuantumOpticsBase.jl as being a light-weight package separate from QuantumOptics.jl
  2. I wanted to have control over my source code to more easily address problems that come up in my work.

I admit that there is considerable overlap between QuantumOpticsBase.jl and QBase.jl, but there are also differences. I think it is important to see QBase.jl as a new contribution to an ongoing discussion within the Julia quantum community. That is, how to build coherence across the Julia quantum ecosystem.

6

First, I’m glad to see some effort on this, there should indeed be some discussion on how to make Julia quantum packages more composable. I’d like to share a few related issues under Yao:

take on the general quantum community in Julia is that it lacks overall cohesion; it’s just a bunch of people writing Julia code for their own quantum projects. My point, however, is that Julia would benefit from an ecosystem of integratable tools for quantum applications. This requires collaboration and cohesion across packages in the Julia Quantum problem space which is simply, the joy of open-source software

However, as a former member of JuliaQuantum, and as the author of quite a few packages under QuantumBFS, I learned a lot of lessons from the failure of JuliaQuantum, JuliaQuantum/QuBase etc.

It’s always good to make an XBase package to solve the name ownership problem, but not the opposite, this is because high-level abstraction needs enough concrete use cases to support. E.g YaoBase is born from the effort of reducing the package size of Yao and make certain interface functions reusable, it is not created in the first place. This is the same for other well-known packages like StatsBase, SciMLBase. The XBase packages should be common code that is moved out from other concrete projects, not the other around.

The failure of JuliaQuantum is mainly because it didn’t start from anything concrete - that is solving a specific problem, it was trying to set a rule, a set of abstractions to follow (e.g start from Base packages, more roadmaps, and code of conduct than code) for people who want to solve problems, which actually creates obstacles for creating new functionalities.

but it looks pretty dead to me

I have removed it from the official website, but haven’t got time to update the website to point to other organizations.

The other lesson I learn from the failure of QuBase is avoiding over-abstraction, writing generic code is good, but not always, especially in a lot of cases it can be hard to write generic code - implementing a top performance simulator for qubit basis just for a single thread CPU is extremely easy (you can do this in one day), but implementing a top performance simulator for arbitrary basis is extremely hard.

In summary, I think it would be much more convincing to show if QBase can actually make Yao, QuantumOptics, and QuantumInformation work together seamlessly, which actually solves a problem than just implementing similar things in an entirely new setup in order to make QBase be “the Base package” for Julia quantum packages.

I hope this helps.

6 Likes
7

This is no doubt part of what’s behind the lack of cohesion that you mentioned. I agree QM in Julia is pretty fragmented, but that may be the natural way for the present. Eg, I notice that many groups are rewriting their own projects, learning what they want.

You might want to make a PR for your projects to this list: GitHub - jlapeyre/JuliaQuantumInformation: List of quantum information and computation projects in Julia

I sometimes think something even more stripped down might serve better as a partial base, even for one’s own projects. Maybe just something to generate the required matrices representing gates with no abstraction on top.

Another route is to make smaller packages. For example GitHub - jlapeyre/ILog2.jl: integer valued base 2 logarithm. It’s hard to imagine anyone needing to implement their own version of ilog2, and it’s faster and cleaner than Int(log2(x)), which is what everyone does.

Another thing, which is is very common, and I see it in QBase, is to hard code some notion of closeness in your predicate functions, (eg ishermitian) . I wrote GitHub - jlapeyre/IsApprox.jl: Interface for approximate and exact equality to provide a simple framework to allow specifying different notions of closeness in a uniform, zero-runtime-cost way. Something like this, which is narrow in scope, but addresses a very common problem, has a chance of getting broad buyin.

3 Likes