unitaryfund / mitiq

Mitiq is an open source toolkit for implementing error mitigation techniques on most current intermediate-scale quantum computers.

Mitiq is a Python toolkit for implementing error mitigation techniques on quantum computers.

Current quantum computers are noisy due to interactions with the environment, imperfect gate applications, state preparation and measurement errors, etc. Error mitigation seeks to reduce these effects at the software level by compiling quantum programs in clever ways.

Want to know more? Check out our documentation, chat with us on Discord, and join our weekly community call (public agenda).

Quickstart

Installation

pip install mitiq

Example

Define a function which takes a circuit as input and returns an expectation value you want to compute, then use Mitiq to mitigate errors.

import cirq
from mitiq import zne, benchmarks


def execute(circuit, noise_level=0.005):
    """Returns Tr[ρ |0⟩⟨0|] where ρ is the state prepared by the circuit
    with depolarizing noise."""
    noisy_circuit = circuit.with_noise(cirq.depolarize(p=noise_level))
    return (
        cirq.DensityMatrixSimulator()
        .simulate(noisy_circuit)
        .final_density_matrix[0, 0]
        .real
    )


circuit = benchmarks.generate_rb_circuits(n_qubits=1, num_cliffords=50)[0]

true_value = execute(circuit, noise_level=0.0)      # Ideal quantum computer
noisy_value = execute(circuit)                      # Noisy quantum computer
zne_value = zne.execute_with_zne(circuit, execute)  # Noisy quantum computer + Mitiq

print(f"Error w/o  Mitiq: {abs((true_value - noisy_value) / true_value):.3f}")
print(f"Error w Mitiq:    {abs((true_value - zne_value) / true_value):.3f}")

Sample output:

Error w/o  Mitiq: 0.264
Error w Mitiq:    0.073

Calibration

Unsure which error mitigation technique or parameters to use? Try out the calibration module demonstrated below to help find the best parameters for your particular backend!

See our guides and examples for more explanation, techniques, and benchmarks.

Quick Tour

Error mitigation techniques

You can check out currently available quantum error mitigation techniques by calling

mitiq.qem_methods()

Technique	Documentation	Mitiq module	Paper Reference(s)
Zero-noise extrapolation	ZNE	mitiq.zne	1611.09301 1612.02058 1805.04492
Probabilistic error cancellation	PEC	mitiq.pec	1612.02058 1712.09271 1905.10135
(Variable-noise) Clifford data regression	CDR	mitiq.cdr	2005.10189 2011.01157
Digital dynamical decoupling	DDD	mitiq.ddd	9803057 1807.08768
Readout-error mitigation	REM	mitiq.rem	1907.08518 2006.14044

See our roadmap for additional candidate techniques to implement. If there is a technique you are looking for, please file a feature request.

Interface

We refer to any programming language you can write quantum circuits in as a frontend, and any quantum computer / simulator you can simulate circuits in as a backend.

Supported frontends

Cirq	Qiskit	pyQuil	Braket	PennyLane	Qibo

You can install Mitiq support for these frontends by specifying them during installation, as optional extras, along with the main package. To install Mitiq with one or more frontends, you can specify each frontend in square brackets as part of the installation command.

For example, to install Mitiq with support for Qiskit and Qibo:

pip install mitiq[qiskit,qibo]

Here is an up-to-date list of supported frontends.

Note: Currently, Cirq is a core requirement of Mitiq and is installed when you pip install mitiq (even without the optional [cirq])

Supported backends

You can use Mitiq with any backend you have access to that can interface with supported frontends.

Citing Mitiq

If you use Mitiq in your research, please reference the Mitiq whitepaper using the bibtex entry found in CITATION.bib.

A list of papers citing Mitiq can be found on Google Scholar / Semantic Scholar.

License

GNU GPL v.3.0.

Contributing

We welcome contributions to Mitiq including bug fixes, feature requests, etc. To get started, check out our contribution guidelines and/or documentation guidelines.

Contributors ✨

Thank you to all of the wonderful people that have made this project possible. Non-code contributors are also much appreciated, and are listed here. Thank you to

• @francespoblete for much of Mitiq's design work/vision

Contributions of any kind are welcome!

mitiq's Issues

Re-using the same Factory object results in unexpected behavior due to stored state

An example of something a user might expect (or at least I expected) was that I could do something like the following:

fac = RichardsonFactor([1.0, 2.0, 3.0])
for setting in list_of_settings:
    zne_data = execute_zne(settings, fac)

The purpose of this is to test different settings against the same factory type.

It turns out that this does not work since the same factory object accumulates more state each time you run execute_zne. This can be solved by redefining the factory in the inner loop, however I believe this is unexpected and unintuitive behavior.

We should consider a workflow that allows factories to have the same type but have their in and out stacks reset when they are reduced. This would be one way to solve the issue.

Do others have suggestions on other ways to solve this? @andreamari @nathanshammah @rmlarose

I'll take this one on as I think I have an idea on how to go about it by having the default behavior for execute_zne to reset the factory when reduce is called. In cases where one does not want to reset after reduce (which is for a different kind of testing) this can be an optional flag.

Clean up library structure

We currently have a lot of bits and pieces lying around without the clearest structure. For the pre-alpha release, we should clean this up.

To me, a reasonable organization is as follows:

folding/
    folding_cirq.py
    folding_pyquil.py
factories/
    factories.py
    zne.py
utils/
    qiskit_utils.py
    pyquil_utils.py
    matrices.py
tests/
    test_folding_cirq.py
    test_folding_pyquil.py
    test_factories.py
    (other tests)

And, we will add a "conversions" directory with functions to convert between circuits.

Open for comments and discussion.

Folding in Cirq for multi-qubit circuits

Folding a subset of gates (fold_gates) in Cirq iterates over moments instead of gates.

I propose we rename fold_gates to fold_moments and add another method fold_gates which correctly iterates over scheduled operations to fold a subset of gates. The latter is implemented in #7

Implement first prototype of adaptive fitting

A first implementation can be based on @tudorgt's notes for iteratively adding points for exponential fitting.

This depends on #14

Raise custom error when attempting to fold gates which do not have a defined inverse

Current folding methods use library-specific errors when trying to invert a gate which doesn't have a defined inverse. In the future, when we decide on an underlying circuit representation & write/use conversion methods, we should define our own error to (1) reduce size of traceback and (2) not confuse users by, e.g., throwing a Cirq error when they input a Qiskit circuit.

Continuous Integration should test both qiskit and pyquil integrations of the library

import mitiq fails

This is another dependencies thing. In a new virtual environment, the following code results in an import error.

pip install -e .

import mitiq

The error is

ModuleNotFoundError: No module named 'pyquil'

when mitiq/__init__.py attempts to import Program from pyQuil.

This is because pyQuil is not a dependency for mitiq (but is for mitiq/pyquil). Of course similar behavior will happen with importing QuantumCircuit from Qiskit.

While we could argue one should not run import mitiq, I feel like its such a common thing this is going to repeatedly pop up -- especially for first-time users as this is a standard thing to do to learn the library.

Option 1

Sound the alarms frequently and loudly to not import mitiq.

Option 2

Something else to handle this dependency subtlety.

Thoughts and ideas welcome!

Begin writing mitiq documentation

The library should be documented enough so that external collaborators can figure out how to use it without developer communication.

First step: Agree on a documentation style, e.g. markdown, rst, etc. I think Will and Nathan have the most experience here, and we should open an initial discussion thread in this issue. I'm a bit partial to markdown for its simplicity but hear that other styles have more sophisticated functionality.

Pinging @willzeng @nathanshammah and @andreamari for thoughts.

Add examples with different frontend/backend combinations

If the library works as intended, different frontends/backends should really work together seamlessly, but it will still be good to highlight this functionality by showing explicit examples. There are in principle four different combinations as of now since we support two frontends and two backends.

• Cirq frontend with Qiskit backend.
• Qiskit frontend with Qiskit backend.
• Cirq frontend with Cirq backend.
• Qiskit frontend with Cirq backend.

Self-assigned but collaborators welcomed.

Add continuous integration from github action on pull request from fork

In PR #47 tests are not run. Tests are run using GitHub actions. As suggested by @andreamari, it looks like this is due to the fact that #47 is a made from a fork of unitaryfund/mitiq.

As pointed out by @willzeng, this should be addressed by editing the continuous integration (CI) workflow.

I can set this up in my fork, but also for the future (external collaborators or forks) I think it's most straightforward to set this up in the generic way. It may be that

on: [push]

in .github/workflows/ci.yml is not enough to trigger the test.
It may be that

on: [push, pull_request]

would work.

If I understand correctly, there can be even more general events that trigger the CI, as a pull_request_review, which looks useful.

I can change the ci.yml file. I also need to become familiar with webhooks.

Github CI tests master as well as the opened branch

There is an example of this in #72

Strangely the github actions CI is not behaving as expected. The failing tests here are failing because of the flake8 problem on master (see #76 ) not because of code on this branch.

The tests that pass are just testing this branch, which does pass.

It isn't clear to me why the pull_request trigger is testing the master branch.

Any ideas?

Update `unitary_folding` function in `folding_cirq.py`.

Updates include:

• Using _get_num_to_fold
• Checking for (terminal) measurements.
• etc.

Check for measurement gates in PyQuil folding functions

Same as issue #22 but for PyQuil: folding functions should ignore measurement gates.

Check for measurement gates in Cirq folding functions

Folding functions should ignore measurement gates and continue to try to fold other gates. No unit tests currently check circuits with measurements in them.

Add qiskit example to getting started docs

It would be good to also show a qiskit version of the example in the getting started from #72.

Simplify the structure of Factory objects

After implementing some extrapolation algorithms I noticed that two aspects of the current structure of Factory classes can be confusing:
A. instack and outstack are internal variables but are also arguments of all methods.
B. instack and outstack are currently updated in different moments and by different functions.

Based also on my last call with Will, I would propose the following changes:

1. Remove instack and outstack from the arguments of all methods of Factory. Ryan had the same suggestion for the reduce method, I agree and I would do it for all, even for _init_. The motivation is that, in my opinion, instack and outstack should simply represent a record of what has been actually experimentally measured, and so they should always be initialized as empty lists.
2. Factory.step should not change instack and outstack. It should only output a single next_param .
3. A new method (e.g. Factory.feed(param, result)) should be used by the mitigate function to append new data points (param and result) to instack and outstack. This should be the only way of updating instack and outstack.

Renaming suggestions:

4. Ryan proposed to rename Factory to BaseFactory or AbstractFactory.
5. Will proposed to rename Factory.step to Factory.fetch.
6. I am open to better names for Factory.feed. Factory.push :-) ?

If you have other suggestions, maybe it is useful to continue the previous enumeration (7... 8...).
In this way it is easier to give feedback on specific points.

As soon as we find a reasonable consensus I can do a PR.

Make Pauli matrices in `/matrices/` functions

I was thinking: what about making the Pauli matrices in mitiq/matrices.py as functions (simply npI(), etc.)?

Should refolding be allowed

This issue has two parts:

1. In fold_gates_at_random gates can be sampled multiple times AND (because the new circuit is built up iteratively, folded gates can also be sampled. IMO it should be possible to resample the same gate but we should not be sampling from folded gates.

2. In fold_local , if you are stretching by more than 3X, then multiple folds need to be made to get to the target stretch. IMO this type of refolding should be allowed (I don't see away around it to get to the target stretch).

This extended the conversation raised in #10 What do you think @andreamari @rmlarose ?

Add a license

The repository needs a license.
Apache 2.0 seems the way to go. Licenses should also comply with parts of code of other libraries that are used. Since pyquil, Cirq and Qiskit are on Apache 2.0, that is also the easiest way forward in view of current and future plugins (let me note that the basic Python scientific ecosystem is on BSD-new 3.0 however).

Just as an information, an agnostic comparison table is available here and a commentary here.

Add the list of our built-in factories to the documentation.

This is to show that we don't implement only linear or Richardson's extrapolation, but there are other options too.

Add background resource links to getting started

The docs should point to useful resources for quantum computing, quantum noise, etc.

This can be in a separate section from the getting started.

Add exponential fitting

Add a reduce method that fits an exponential curve

Folding functions should retain circuit properties (e.g., num shots) and device information (e.g., qubits, connectivity, etc.)

Our current folding techniques for Cirq build the folded circuit from an empty circuit. Circuits in Cirq can be tied to a device which tells information about qubits, connectivity, and gate operation times. As such, I think it's more appropriate to copy the input circuit and insert gates to do the folding. Thoughts?

Allow for (optional) reduction of circuit depth after folding

Current Cirq folding functions use the convention of inserting two new moments per gate fold, namely G -> G G^dagger G. The primary reason for this is to make indexing the new circuit simple -- every insertion in moment m shifts every moment after m by two.

This has the perhaps undesirable effect of creating a bunch of new moments in the circuit. (Or, from a hardware implementation perspective, it might be beneficial to have "virtual" gates in their own moments, I don't know.)

There are three options:

(1) Don't decrease the number of moments.
(2) Decrease the number of moments by more careful indexing inside the folding functions.
(3) Decrease the number of moments by "collapsing" gates into the same moment as much as possible after the current folding functions are called.

I tend to think that (3) is the best option as it allows for both possibilities that it's beneficial to have virtual gates in new moments on hardware, or that it's not.

To implement (3), I propose writing a new function which implements the collapsing procedure, and adding a boolean argument to fold methods to specify if this should be called after the folding or not.

So, the changes would be adding the function

def collapse_gates_into_moments(circuit: cirq.Circuit) -> cirq.Circuit:

and modifying fold methods for the new input:

def fold_local(
    circuit: cirq.Circuit,
    stretch: float,
    fold_method: Callable[...],
    fold_method_args: Tuple[Any],
    collapse_gates_into_moments: bool = False
)

Remove qiskit dependency in zne.py

This import is there to check the type of a quantum program and branch to a different default behavior if the program is a qiskit one. This was reported by @yhindy

Once #93 is merged we will be able to translate smoothly between circuits and so this branch (and the import) will no longer be necessary.

Once #93 is merged I'm happy to take this one.

Quantum Program types adds dependencies and is hard to read in docs

This issue is about two things:

[1] Currently the type signatures end up looking hard to parse in our docs. E.g.

[2] Using QuantumCircuit types introduces a dependency on the library wherever it is used.

Both of these things will likely get worse when more types are added.

It would be better if the docs for this function read:

mitiq.zne.mitigate_executor(executor: Callable[[QPROGRAM], float], fac: mitiq.factories.Factory = None, scale_noise: Callable[[QPROGRAM], float], QPROGRAM] = None) → Callable[[QPROGRAM], float]

To achieve this we could just define a dummy class:

class QPROGRAM():
    pass

That serves as a labelled placeholder.

While this wouldn't check types of code, it would solve the above issue.

Any suggestions on how to solve the above issues while retaining type checking? That would be the best outcome.

@rmlarose @nathanshammah @andreamari

Add Getting Started: minimal example of ZNE (with any frontend/backend)

To show the absolute essentials of the library, its purpose, and how to minimally use it.

Make a release, decide versioning and understand Github packaging

• The button "release" on top of the menu makes a Github release.(Also, once it will be public, Github releases maybe can be used to automate conda releases.)
• We need to agree on version number. What about "mitiq v0.1-alpha"? or beta? I have no strong feelings about it.
• There is the possibility to release "packages" hosted by Github, also for private repositories. Still understanding what it means.
• We could add a markdown file with information on how to make a release (it will have pip and conda too, and mention updating the documentation).
• I did not register mitiq on pypi and test-pypi, as some package and related info needs to be uploaded. Not sure if they would allow an empty package to be there.

Make `Factory` a proper abstract class

If a Factory is an abstract class, we should inherit from ABC.

This is more pythonic, PEPy, and makes it clearer which methods must be implemented by the user in order to define a valid custom Factory. (This came to mind when reading the docs on how to define a custom factor.)

Set standard on line length limit and reformat existing ones

It may be best to limit line length in .py file for readability.
This is showing up especially in the documentation api-doc.
In PEP 008 it was proposed to be 79 characters for code (and 72 for comments).
I think we could choose whatever but since all is arbitrary, 79 characters could be the way to go overall.

There is a nice tool for code formatting that helps with this and other stuff, it's black (pip install black).

An example:

black zne.py --line-length 79

After using it, usually it is best to check its choices as sometimes line breaking are awkward.

Showing by default a line ruler can help in prototyping. In Sublime, this can be changed in Preferences.

I can run black on all modules and we could remember to check with it before the final push in PRs.

Handling circuit conversions without explicit dependencies

I'm working on different frontend/backend combination examples and ran into the following important consideration. Consider the simple example:

import qiskit
from mitiq.folding import fold_gates_from_left

circuit = qiskit.QuantumCircuit(...)  # Some qiskit circuit

folded = fold_gates_from_left(circuit, stretch=2.)

This raises an error of course as folding methods are defined for cirq.Circuits. However, it would be very convenient to be able to run this code. If we could run this code, all of the conversions could be handled in the folding methods, and very little changes, if any, would be needed elsewhere to handle conversions.

However, I don't see a way to do this without requiring Qiskit/pyQuil/etc. in the main mitiq library. This is simply because we need to check what type the circuit is in order to convert it properly.

Option 1: Require Qiskit/pyQuil/etc. as dependencies

This fixes the issue, but is rather inelegant.

Option 2: Check the type without dependencies

Check what type the circuit is without requiring all dependencies, then call the appropriate conversion code. This seems like magic to me, but if it could be done that would be amazing. (Can it be done with typing._ForwardRef? I don't think so, but I'm looking into it now.)

Option 3: Frontend-specific folding methods

One way to do this which avoids requiring Qiskit/pyQuil/etc. in the main mitiq library is to define folding functions in mitiq/qiskit, mitiq/pyquil, mitiq/etc. These folding functions would do the conversions then call the internal folding functions using Cirq circuits. So the example above would be modified to

import qiskit
from mitiq.qiskit.folding import fold_gates_from_left

circuit = qiskit.QuantumCircuit(...)  # Some qiskit circuit

folded = fold_gates_from_left(circuit, stretch=2.)

This is a bit clunky, and I still think mitiq would have to depend on Qiskit/pyQuil/etc. in order to run functions in zne.py properly.

Conclusion

I'm still trying to think of the best way to handle this. Any feedback is welcome, specifically on Option 2 as this would be very nice if its possible. Additional ideas welcome.

Format docstrings

We could agree on the format to follow from now on in docstrings.

Once we do, I'd like to format the docstrings in the .py files, as part of the main Documentation effort, #34 (I'll open a pull request for this).

Provided that we are free to do as it suits us best, there are two Python Enhancement Proposals (PEP) that can be looked up for this: PEP 8 (Style guide) and the more precise PEP 257 (doctrings conventions).

I find it useful also to look at well-documented libraries such as Numpy, Matplotlib and so on, as they also build some easily explorable documentation.

I propose to use the format of this example:

def num_dicke_states(N, rho):
    """Calculate the number of Dicke states.

    Parameters
    ----------
    N : int
        The number of two-level systems.

   rho : :class: `qutip.Qobj`
        The density matrix.

    Returns
    -------
    nds : int
        The number of Dicke states.
    """

This tells

• the input
• the output
• the type of both

Besides the formatting, I think it is important to add what is the output of functions and methods to the current code.

It may be neat to format, if not all, some particularly important objects, already in view of cross-referencing (internal links) and external links to other projects using intersphinx. For example using:

:class: `qutip.Qobj`

Once the documentation is built, it allows the object type to be clicked upon and brings the user to the requested page, in that documentation or elsewhere.

Create getting started and installation

For the beta release we'll need a getting started that shows how to install the library and shows examples of how to use the library.

I propose that the examples show one how to:

• Mitigate a simple cirq quantum program on a cirq backend.
• Mitigate a simple qiskit quantum program on a qiskit backend.
• Mitigate a simple cirq quantum program on a qiskit backend.

Other suggestions for the getting started?

Add support for Python 3.8

In the continuous integration workflow, a Python 3.8 environment could be set up. I noticed that I use Mitiq already in a Python 3.8 mini-conda environment, as this is the default now when one creates a new environment.

Better error handling for circuit conversions

Main idea: It's potentially confusing for users to see an error from a platform they are not using. This could arise when handling circuit conversions. We should catch these lower level errors and display custom errors from Mitiq.

Use cirq as internal representation

In #31 and #32 Ryan suggests that for the alpha release we just use the cirq internal representation. I agree with this. Cirq already has built in import and export to QASM which means it is especially easy to support qiskit and cirq together. Cirq also has some open issues about export to Quil.

To me this is enough of a case that cirq is (for the time being at least) preferred as an internal representation over pyquil. Thus I propose that we remove the pyquil internal representations and just use cirq. This reduces the maintenance burden on our code and will help us clean up the dependencies and structure.

Do you agree @rmlarose @andreamari @nathanshammah ?

Add capability to automatically test code in documentation

Create support for IBMQ Backends

We should have functionality to submit jobs to IBMQ for the pre-alpha release. The most basic functionality includes submitting a job to a designated backend, which we should focus on for now.

The key obstacle I can see is handling API keys and registered accounts for IBMQ. I don't see a clear best way to do this yet, hopefully there is at least a good way.

In the future, we can build on the basic support here to batch jobs, target the backend with smallest queue, print status updates, etc.

Pin to specific Qiskit, pyQuil, and Cirq versions in requirements

Just ran into an issue where Qiskit circuit data is stored differently between v0.0.15 and v0.0.16, causing local tests to pass but the build to fail.

To avoid similar issues in the future, we should pin to specific versions now. @willzeng thoughts on what the versions should be? Latest?

Note that PR #42 pins Cirq to version 0.0.7.

Add example on factories + how to make a custom factory and use it

Add example on folding methods + how to use a custom folding method

Add scipy to requirements and consider downgrading numpy

scipy is called in factories.py.
Can downgrade numpy.

[Discussion] Zero noise extrapolation with multiple expectation values

For many applications, e.g. VQE, the final observable to perform ZNE on is a linear combination of expectation values. Our primary design focus has been on a single expectation value. Being able to handle multiple expectation values will be, I would say, an essential feature even for beta testers.

We should discuss how to handle mitigating multiple expectation values with Mitiq. Here's one idea:

For VQE and many similar variational-type algorithms, there are two key components that go into the circuits which get run: (i) the ansatz and (ii) the observables to measure. From a unitary folding perspective, it is very easy to just input the ansatz circuit and fold that, then pass this folded circuit to the run method which handles the multiple observables to measure. It might make sense to make (or use an existing) class for weighted Pauli operators or something similar. This would then be passed into the run method, and Mitiq would form all the circuits to run, run them, and recombine the expectation values to do the extrapolation.

There are some questions that arise in this discussion which I don't immediately know the answer to. E.g., is it better to extrapolate each expectation value separately then combine them, or combine them then do the extrapolation. (Is extrapolation linear? What is better in terms of design? Runtime?)

Please use this thread to discuss, propose additional ideas, etc. (@willzeng this was the last item I wanted to discuss in today's engineering meeting.)

Folding with stretch close to one returns no output

Multiple easy fixes, one is to take num_folded >= num_to_fold as a stopping condition in, e.g., fold_gates_from_left, as opposed to the stopping condition num_folded == num_to_fold. For very small stretches, num_to_fold can start out at zero.

Buggy Richardson extrapolation?

From my folding method benchmarks, I'm finding that Richardson extrapolation returns some nonsensical results. For example, consider the following MWE:

import numpy as np
from mitiq.factories import RichardsonFactory

# Noise and expectation values from an experiment
noise = np.linspace(1., 3., 20) * 0.10
expectation_values = [0.5643, 0.5513, 0.5407, 0.533, 0.5255, 0.5195, 0.5156, 0.5125, 0.5086, 0.5059, 0.5033, 0.502, 0.5011, 0.5003, 0.4998, 0.4987, 0.4982, 0.498, 0.4978, 0.497]

fac = RichardsonFactory(scalars=noise)

fac.reduce(noise, expectation_values)
# Returns -51817538.17675539

Am I missing something here or is this a bug?

Benchmarking ZNE against MAXCUT

PR #94 introduces benchmarking code that allows our ZNE methods to be tested against randomly generated n-qubit quantum circuits.

We have also discussed wanting to benchmark our performance on a variational algorithm.

Proposal

This issue proposes to add a new module maxcut_py to /benchmarks that runs MAXCUT problems on random graphs and evaluates how the mitigated result compares to the unmitigated result.

Background code

It is likely easiest to do all of our base benchmarking in cirq, as is done in the random circuits example. This means we don't have to worry about circuit conversion and can take advantage of the convenient noise simulation built into cirq.

Cirq does not have a well maintained QAOA/MAXCUT implementation, but they do have an example here. The example isn't great and perhaps we could maybe upstream an update to it when we do our implementation.

Wanted to see if you all thought this was a good idea before moving forward on it.

@andreamari @nathanshammah @rmlarose @tudorgt @yhindy

Add linear, polynomial, and Richardson reduce methods

These will be added in the framework from #6 and at least will include:

• Richardson extrapolation
• Linear fitting
• Polynomial fitting

@andreamari Am assigning to you as you are already working on this.

Continuous Integration (CI): Add print of docstring for tests run with pytest and doctest

I think it would be nice to print to screen in the job log in the github actions the docstring of the tests run with pytests. There can be many tests in each module.

One needs to add some verbosity feature to pytest. Not sure it will print to screen. --verbosity=VERBOSE or something similar.

We can add doctests also in CI as per #75.

Create circuit conversion from underlying representation (Cirq for now) to allowed backends (Qiskit for now)

For the purpose of running folded circuits on real backends. In the future, we should allow as many backends as possible, including

• IBM
• Rigetti
• Google
• IonQ, Honeywell, etc.

For the pre-alpha release, we will focus on converting from Cirq circuits to Qiskit circuits to submit on IBMQ processors.

Create circuit conversion from allowed frontends (Qiskit for now) to mitiq representation (Cirq for now)

For the purpose of unitary folding (which inputs Cirq circuits). In the future, we should allow for many front-end circuit types, including

• Qiskit
• pyQuil

and others. For the pre-alpha, release, we will focus on Qiskit QuantumCircuit's as the primary allowed front-end and Cirq Circuits as the underlying representation used to fold gates.