Good documentation is paramount to the success of any open source project, especially for a robust and feature-packed framework like qbitkit. Our API documentation is very extensive to say the least, but this alone is not enough. We want our users to dive right in and adapt to any learning curves qbitkit presents as fast as possible, and asking people to just dig through the API doc to figure out what they need for a project will probably turn people away. There's many other great reasons to have a more well documented qbitkit, but the primary goal of qbitkit is to make things easy, and the only way to ensure we are meeting that goal is to make sure our users have everything they need to build robust applications for the next generation of computation.

Finance is a great use case for quantum. qbitkit users could greatly benefit from built-in functions to make tasks like portfolio optimization as easy as possible.

IBM Quantum Experience Support

IBM Quantum is more or less the only quantum platform that is truly free to the public. One of the foremost goals of qbitkit is to empower as many people as possible to create novel solutions with quantum, and I believe IBMQ support will help us achieve this goal. The history of classical computers is absolutely mired in straight white male privilege, and with quantum we honestly have a responsibility to do better. By making it easy to write code for quantum computers once and run it anywhere, including free platforms like IBMQ, we might actually be able to significantly reduce the amount of privilege required to learn and use real quantum computing!

Progress

At the time of writing this issue, the translation function for IBMQ is just copy-paste from the translation function for Braket, with any lines containing IBMQ circuit elements not present in the dependency for IBMQ (qiskit) removed as nonexistent functions were removed to silence errors produced by my linter.

Cirq Support

Cirq is a quantum library by Google. It does indeed have support for Google's quantum hardware, making the prospects of integrating Cirq into qbitkit quite appealing. Cirq doesn't look that much different at first glance from the other providers we've integrated thus far (IBMQ, AWS Braket) so supporting Cirq likely won't be too much development overhead. Also, just speaking as a trans developer, I think it's worth backing those seeking to foster inclusive communities -- otherwise people like me don't really have as many comfortable places to be.

Quantum chemistry is a really amazing application of NISQ-era gate-model quantum computers. That said, it's lots of work to figure out how to implement a VQE ansatz, compute expectation values of the Hamiltonian operator for your molecule, iteratively adjust the theta of your ansatz and re-run the circuit, and so on. All of these things, if they were implemented in qbitkit would make quantum chemistry much easier. Some ideas for high-level functions that abstract daunting tasks include calculating ground states, excited states, and electronic structure. These are all things that have been done on gate-model quantum with code examples that can be adapted into qbitkit.

Support Honeywell Quantum

Value of Feature

Honeywell, a company with experience in designing and manufacturing much of the support hardware needed for quantum computers has recently begun to give the public access to their high fidelity quantum computers HØ and H1. These are their first two quantum computers, and based on their claims it looks like they have some pretty compelling hardware features. First, both models support mid-circuit measurement. This is a game changer and allows us to run certain types of circuits we simply were unable to prior to the introduction of these devices. Their coherence times are very impressive for NISQ-era quantum. HØ and H1's T1 coherence time is >10^6 seconds. T2 coherence times are also quite impressive with the T2 coherence time on HØ being about 2 seconds and the H1 T2 coherence time about 3 seconds. High-resolution rotations are made with a laser similar to IonQ, allowing for more precise execution of circuits including gates such as RX, RY, and RZ. Lastly, similar to IonQ's topology, both HØ and H1 have full connectivity.

Barriers to Completion

Currently you have to personally contact Honeywell, get a quote, purchase an amount of credits for which there is a minimum purchase requirement, and probably pay quite a lot of money. These things are threats to my ability to adopt support unless I can secure funding for qbitkit, so it isn't yet clear if or when this feature will be implemented.

Currently, the way a qbitkit user defines gates is using a Dictionary passed to a function that makes a Pandas DataFrame out of the dictionary. Why not cut out the middle man and just use dictionaries to define circuits? This shouldn't be too difficult, and definitely needs to be resolved soon. The point of qbitkit is to be simple, and adding on an unnecessary layer takes away from qbitkit's ability to achieve that goal.

Expected behavior: Pass instruction and target qubit ints to translate_circuit(), get the gate you asked for appended to the input circuit you specified
Actual Behavior: any gate you pass for some reason won't trigger any of the if statements
Last Working: This never worked.
Reproduction Steps:
Known Affected Platforms: Tested on Windows 10 with Anaconda3.8, AWS SageMaker for Braket using the conda-braket environment included , and vanilla Debian 10 with python3-pip from apt-get.

Also, FIRST! Though this issue was made before the qbitkit repo was publicly released, so it's not like any of you had a chance anyways... Fingers crossed this is the first of many issues I use to improve qbitkit as more and more people use it

Annealing Support (#5) is starting to come together, so it's time to start thinking about supporting D-Wave's Leap platform. Implementing this should be relatively straightforward as only a few functions make up provider-specific code for annealing in qbitkit. Leap supports samplers and solvers that leverage a combination of high performance compute and their Advantage quantum annealer with well over 5,000 qubits.

With the way provider support is currently implemented, libraries for specific providers are required. This made the development of qbitkit easy, but adds a significant amount of bloat while increasing the number of things that can go wrong. To mitigate these issues, qbitkit should use the requests library to interact with providers using their APIs.

🚢 Kubernetes Support

3 Docker container images are included in this repository, two for the infrastructure to host qbitkit documentation, another to host documentation and the qbitkit homepage, and the third image is a Jupyter Notebook server with qbitkit installed and ready to roll. The first 2 images get deployed to cluster A, the third gets deployed to dedicated cluster B. To ensure all deployments of this image remain up-to-date, a deployment YAML configuration containing the image to be deployed and a cloudflared sidecar will need to be created for each image.

Giving qbitkit a nice new home!

Upon public release, we need to create a new organization to hold qbitkit as well as any additional repositories we want to add subsequently. This is de-facto best practice and will make us look 100% more professional.

Feasibility

Literally the easiest issue to solve.

Considerations

• To make things look cleaner, a direct fork shouldn't be made -- the repo should be imported instead. This way we wont have forked from brianlechthaler/qbitkit stapled to the top left of the repo.

• Extra care should be taken to migrate ALL repo contents, including but not limited to:

• Issues

• Pull requests

• Projects

• Before marking read-only we need to do the following things to ensure this repo does not get mistaken for where we are migrating it to:

  • modify repo description, readme.md to clearly indicate the repo has moved
  • put links everywhere to the new repo
  • rename the original repo to avoid search confusion
  • create a new default branch with just a readme explaining the move to make it extra difficult to accidentally clone this thinking it's the new qbitkit

• After the repo has successfully been moved and we're 100% sure we're ready to make brianlechthaler/qbitkit read-only , we archive that original version

Do our users even know "we" just refers to one person? Probably not, this repo is currently marked as private and I'm actually just talking to myself.

There is currently no documentation for the quantum logic gates that can be translated. This needs to be remedied or else the only way to get this information is digging through source code, which is not optimal.

Strawberry Fields (by Xanadu) Support

Xanadu has been putting room-temperature photon-based quantum (aka quantum photonics) in production for a little while now and this may very well become a widely used platform. Similar to how supporting qbitkit supporting Qiskit means we have IBM compatibility, Xanadu's Strawberry Fields support will mean that we can unlock the potential of devices compatible with Strawberry Fields.

Feasibility

I've looked through Xanadu's documentation on Strawberry Fields, and from what I can tell supporting SF would not actually be that much harder than supporting other vendors like IBMQ or Braket.

Progress

Nothing for now.

Please don't sue me, Apple Records. I'm not talking about the Beatles, I promise.

Field names for different parts of the circuit DataFrame such as gate , targetA, phi should be customizable. This would be accomplished by adding a parameter to define a custom name for each row name into translate_gate(). Should not take very long, so I have decided to mark this as low-hanging fruit.

As qbitkit continues to support an increasing number third-party quantum libraries, hardware, simulators, and platforms, our requirements.txt grows ever longer as does the total installation size of qbitkit.

How Things Are Now

All of these elements are part of qbitkit and are bundled together:

• Logging (Elasticsearch)
• Provider Support (Braket, Experimental IBMQ)
• I/O and DataFrames
• & everything else in-between

How Things Should Look

Main Repository

This would be the "core" qbitkit, that would require a plugin be installed and that specific plugin to be imported alongside core qbitkit.

• Logging
• I/O & DataFrames
• All other basic functionality that is not tied to any providers

Provider Repositories (Logic Gate)

qbitkit-provider-braket

(full support) AWS Braket Gate-Model QPUs and Simulators

qbitkit-provider-ibmq

(experimental) IBM Q through Qiskit

• See #2 for more info on support for IBM Q

qbitkit-provider-strawberryfields

(future) Strawberry Fields Photonic Quantum Toolkit

qbitkit-provider-rigettiqcs

(future) Rigetti QCS through Forest

qbitkit-provider-circ

(future) Google Quantum through Circ

Provider Repositories (Annealing)

qbitkit-annealing-provider-braket

(in progress, see #5) D-Wave Quantum Annealing through Amazon Braket

• I/O & DataFrames
• Everything else

This is a recommended convention for class names in Python. To align with this convention, I'll have to manually change the first letter of each class name to be uppercase. Not that hard, to be honest.

Support logging to Elasticsearch

Elasticsearch is a schema-less database, meaning you can index any set of key-value pairs and search through them without worrying about structuring data like you would for a CSV file. This is great for our purposes. We'll need to send raw result data from the quantum computer or simulator qbitkit is talking to, and this data and it's structure varies greatly between different QPU or simulator vendors, platforms like Braket or IBMQ, and even the size of the circuit you are running.

Feasibility & Progress

Elasticsearch has 3 ways to read/write with Python:

• elasticsearch Standard, low-level Elasticsearch client.
  • supported at time of creating this issue
  • has not been tested
  • has not been carefully reviewed
• elasticsearch-dsl Easier-to-use high-level Elasticsearch client that uses Elasticsearch's domain-specific-language.
  • This won't be supported, there's currently no compelling reason to support this library in qbitkit
• eland Elasticsearch client that reads and writes in DataFrames.
  • This may be supported in the future or replace the standard low-level Elasticsearch client as our default way of reading/writing to a database

Unit tests should preferably be implemented in pytest, as that seems to be the best option for our use case. Unit tests are vital to having a healthy codebase, and need to be implemented soon.

Local Quantum Circuit Simulation

Allow for execution of quantum circuits on a local simulator for testing and development without the need for any credentials. This is quite helpful when you're on the go without a stable internet connection, or when configuring credentials isn't a great option.

Feasibility

Quantum circuit simulators are bundled with both IBMQ (via Qiskit) and Braket (via braket python sdk) dependencies, and implementing a function per each provider to simulate circuits locally could easily be expressed in just a couple lines of code. This is all to say that this issue could be classified as low effort, high reward.

Is your feature request related to a problem? Please describe.
Nope, this is not related to any problem.

Describe the solution you'd like
DOCPLEX is great for specifying optimization problems and supporting it in qbitkit should not be too difficult.

Describe alternatives you've considered
Qiskit and DOCPLEX are both IBM products, so as you would expect they work together quite nicely.

Additional context
No additional dependencies would be needed as DOCPLEX is installed when you install Qiskit, which is installed when you install qbitkit.

Forest SDK Support

We have already added support for Rigetti to qbitkit through the integrated Braket SDK. That being said, many people who access Rigetti hardware through their organization likely will be doing so through Rigetti's Quantum Cloud Services(QCS) instead of AWS.

What Should be Easy

• Implementing Rigetti's qvm (no relation to Qubes OS) simulator should be fairly straightforward
• The Quil language looks pretty easy to adapt to qbitkit

Obstacles to Implementation

• Access to Rigetti Quantum Cloud. I'm not a member of any organization that has access to Rigetti QCS, so I'd have to figure out. There are two ways to solve this:
  • I have the privilege of US citizenship, which means I can sign up for a program run by Oak Ridge National Laboratory. Their program for letting the public use quantum is intended for researchers who have intention of publishing scientific research, so I'm not 100% positive they would approve a request to use their quantum to work on qbitkit.
  • The Unitary Fund has a microgrant program that offers access to Rigetti's QCS and free credits to use there. As is the case with going the ORNL route, it is up to the decision makers at their respective organizations whether or not they want to give me access to Rigetti QCS for the purpose of working on qbitkit

Is your feature request related to a problem? Please describe.
No, this is a request for a new feature that is not related to any problem with qbitkit.
Describe the solution you'd like
Tools and helpers for Machine Learning on NISQ hardware & simulators.

Describe alternatives you've considered
PennyLane by Xanadu, and Qiskit are both excellent for playing with quantum machine learning.

Additional context
Good resources on this topic:

• https://qiskit.org/textbook/ch-machine-learning/machine-learning-qiskit-pytorch.html
• https://pennylane.ai/qml/demonstrations.html
• https://nextjournal.com/gkoehler/pytorch-mnist
• https://www.tensorflow.org/quantum

qbitctl: qbitkit, but for the command line.

Python is designed to be an easy language, but let's be real: the world isn't made of programmers, it's made by them. Fancy browser applications are very far down the road, but in the short term we need to give users an alternative to having to write code.

Feasibility

Low effort, high reward. Should take an afternoon or less(?)

Progress:

Some work has been done to form the foundations of qbitctl. There is currently some structure for loading files present.

Import statements like this:

import x as y

Will create y in any namespace you import a module containing that import statement. This is just a formality with how Python works behind the scenes, and to make sure users don't get confused. The remedy to this situation isn't that complex, all that needs to happen is import statements like the one listed above need to be reformatted to match the following formatting:

import x as __y__

Just a simple change like that makes a world of difference, especially if you want to explore a library by autocompleting parameters and functions.

The somewhat haphazardly written test cases could use some work, which is what this issue seeks to address. A new branch https://github.com/qbitkit/qbitkit/tree/simplify_testcases has been created to track this effort.

VQE Ansatz Generator

A Variational Quantum Eigensolver is a very powerful tool when creating algorithms for NISQ-era hardware. With applications from 💹 Finance, 🧪 Chemistry, 🔢 Optimization, 🧠 Machine Learning, ⚕️ Healthcare, 🧬 Life Sciences and beyond, VQEs are akin to a "swiss army knife" for NISQ-era quantum algorithms. VQEs can be fine-tuned to solve certain problems by adjusting the VQE's ansatz. Building ansatzes is a pain, and having to re-write them for each provider, framework or library you need is also a massive pain. qbitkit can help make ansatz generation as simple as calling a function, and seamless provider integration in qbitkit means you can stop re-inventing the wheel and focus on re-inventing how humanity solves it's hardest problems. This is just one small yet important piece of a quantum algorithm, any quantum circuit is only as useful as the classical parts of the algorithm can harness it's strength to be. This is, however, a useful feature that would save many people lots of time, so I'm working on making this a core feature available in the near future.

References

Peruzzo, Alberto; McClean, Jarrod; Shadbolt, Peter; Yung, Man-Hong; Zhou, Xiao-Qi; Love, Peter J.; Aspuru-Guzik, Alán; O’Brien, Jeremy L. (23 July 2014). "A variational eigenvalue solver on a photonic quantum processor". Nature Communications. 5 (1): 4213. arXiv:1304.3061. Bibcode:2014NatCo...5E4213P. doi:10.1038/ncomms5213. ISSN 2041-1723. PMC 4124861. PMID 25055053.

Higgott, Oscar; Wang, Daochen; Brierley, Stephen (2019). "Variational Quantum Computation of Excited States". Quantum. 3: 156. arXiv:1805.08138. doi:10.22331/q-2019-07-01-156. S2CID 119185497.

Documentation for qbitkit

As we near closer and closer to minimum viable product and subsequently public release, we need to start to focus on documenting as much of qbitkit as possible.

What needs to be Covered in the Docs

• All modules
  • their functions
    • variables and options for those functions
• Examples in IPython notebook should be made to introduce new users to qbitkit
  • This should be relatively fun and easy

Feasibility

This may take a while, there are actually quite a few functions and configuration variables for said functions so getting to the point where everything is covered in documentation may take about a week or more.

Progress

None

We have a handful of scripts in bin/ that need automated testing to ensure are shipping scripts that work as intended.

Jupyter Notebooks would be an excellent way to demonstrate all of qbitkit's functionality while providing prospective users with an interactive learning experience. I already use Jupyter Lab to test qbitkit functions as I develop them, making accomplishing this goal a little easier.

Support Quantum Annealing

While gate-model QPUs are great for general-purpose quantum compute, Ising machines such as D-Wave capable of quantum annealing excel at combinatorial optimization problems with a very large yet finite set of variables. While you won't be able to run quantum circuits on an Ising machine, qbitkit should still support quantum annealing tasks as they are an integral (if not at times controversial) part of the current quantum computing ecosystem.

Just D-Wave?

Well, yes -- for the time being. All other quantum computing vendors are busy working on their fancy universal gate-model quantum computers while our well-funded Canadian friends over at D-Wave are perfecting their annealing technology. Hitachi has shown some promise with their CMOS Ising machine, but supporting that would be difficult considering these devices are neither in production nor available with SDKs that can be adapted into a qbitkit provider. Aside from Hitachi's fascinating proof-of-concept, and various simulators, D-Wave is basically the only Ising machine worth supporting in qbitkit

Feasibility

We just have to wrap the high-level APIs from D-Wave, few days to maybe a week at most of work

Progress

• none yet

It would be helpful to implement a Qiskit-compatible MinimumEigensolver for use in Qiskit algorithms. Support would have to be added for both braket and leap providers, which is fairly trivial thanks to the D-Wave Qiskit plugin providing a MinimumEigensolver compatible with D-Wave samplers.

QASM is short for Quantum Assembly and as such has syntax and structure similar to Assembly for classical computers. Similar to it's classical counterpart, QASM is the lowest-level language for quantum computing. Various quantum computing libraries support QASM natively and for good reason: it's an open standard for defining circuitry designed to be interoperable with any gate-model quantum computer.

qbitkit offers the ability to define circuits as Pandas DataFrames, and everything you need to test and run those circuits on a very wide range of real or simulated quantum hardware. Having the ability to translate these DataFrames not just into provider-native formats, but also raw QASM will allow greater interoperability now and well into the foreseeable future.