qiskit-community / prototype-qrao Goto Github PK

What is the expected enhancement?

The typical interface in Qiskit Optimzation for performing a quantum optimization is the OptimizationAlgorithm.solve(problem: QuadraticProgram) method. However, a lot happens "underneath the hood" when calling this, and when developing this prototype, we wanted to give users a bit more control over and understanding of what is happening. For instance, if one simply calls this method, they have no way of knowing beforehand how many qubits are necessary for the computation, so they won't know if it can run on a given piece of hardware until they try. So, we provided a more "explicit" interface, where the user must construct the QuantumRandomAccessEncoding explicitly, encode() it with a QuadraticProgram, and then pass it when constructing the optimizer.

However, it would be nice to implement the standard, implicit interface as well. One benefit is that users would then be able to use QRAO with the ADMM optimizer (and we should add a test case for this, once it becomes possible). Another benefit is that it is a prerequisite in case we want to enable the implicit conversion of any convertible QuadraticProgram into a QUBO (#10), just as the other optimization algorithms permit.

Potentially related: qiskit-community/qiskit-optimization#325, if it results in a more general overhaul of the solve() interface.

What is the expected enhancement?

Currently, we use the the Qiskit r gate to return the basis rotation corresponding to the (3,1,p) QRAC:

However, this obscures the connection to the math in the paper. It would be more clear and helpful to the user if we instead implemented these basis transformations explicitly as written in Appendix IV of the paper (that is, with the relevant combination of rx, rz, and pauli x, y, z gates).

I have previously considered that we ought to keep it as a single gate, as that is the most precise way to specify the operation. However, I've since learned abou the Optimize1qGates[Decomposition] passes, which should be able to transpile to the optimal operations on hardware even if given as multiple single-qubit gates.

However, this might be at odds with parameterizing the gates for use with the primitives (#21), so we might want to see how that goes first.

Steps to reproduce the problem

tox -elint is currently broken, as can be seen from the Actions run resulting from the most recent commit to main. The previous run was successful, and the version of mypy has not changed since then. I am suspecting that this has been triggered by a new release of numpy.

What is the current behavior?

lint run-test: commands[3] | mypy qrao tests
qrao/encoding.py:445: error: Invalid index type "Union[int, str]" for "ndarray[Any, dtype[floating[_64Bit]]]"; expected type "Union[SupportsIndex, Tuple[SupportsIndex, ...]]"
qrao/encoding.py:453: error: Invalid index type "Union[int, str]" for "ndarray[Any, dtype[floating[_64Bit]]]"; expected type "Union[SupportsIndex, Tuple[SupportsIndex, ...]]"
qrao/encoding.py:456: error: Invalid index type "Tuple[Union[int, str], Union[int, str]]" for "ndarray[Any, dtype[floating[_64Bit]]]"; expected type "Union[SupportsIndex, Tuple[SupportsIndex, ...]]"
qrao/encoding.py:457: error: Invalid index type "Union[int, str]" for "ndarray[Any, dtype[floating[_64Bit]]]"; expected type "Union[SupportsIndex, Tuple[SupportsIndex, ...]]"
qrao/encoding.py:458: error: Invalid index type "Union[int, str]" for "ndarray[Any, dtype[floating[_64Bit]]]"; expected type "Union[SupportsIndex, Tuple[SupportsIndex, ...]]"
Found 5 errors in 1 file (checked 17 source files)
ERROR: InvocationError for command /home/runner/work/prototype-qrao/prototype-qrao/.tox/lint/bin/mypy qrao tests (exited with code 1)

What is the expected behavior?

It should not error.

And perhaps we should also run the linter Action on a cron job to notice issues like this sooner.

It is useful to have the link to the project docs on the GitHub home page for this repo. (Right now, it's currently the research paper, which would instead be better to be a link from the docs.)

To fix this, go to the "Code"/home page of the repo. Then click the wheel on the "about" section on the right. Set the website to your GitHub pages.

Thanks!

What is the expected enhancement?

Let n represent the value of max_vars_per_qubit. Let's further assume that n is not 1, i.e. it is either 2 or 3. Depending on the variables-to-qubits assignment, it is possible that some qubits will have fewer than n decision variables assigned. However, at the moment, such qubits will still be encoded as an (n,1,p) QRAC. Ideally, the encoding on each qubit will be "adaptive," such that it uses an (m_i,1,p) QRAC, where m_i is the precise number of decision variables assigned to that qubit.

This is not difficult to fix, but we need to fix #7 first (update: done!); otherwise, magic rounding would no longer work generally.

What is the expected enhancement?

To be able to solve the same problem with CPLEX solver as provided by Qiskit here:
https://qiskit.org/documentation/optimization/stubs/qiskit_optimization.algorithms.CplexOptimizer.html

Having classical (CPLEX) solver will make it easier to compare the results.

What is the expected enhancement?

It would be nice to test whether QuantumRandomAccessEncoding.encode() (see encoding.py) encodes the Hamiltonian correctly (as stored in qubit_op, and -- for now, until #14 is merged -- offset) when given some small QuadraticPrograms explicitly. Having some explicit tests would fully ensure all the factors of 2 and minus signs are right. We are confident in its current state, but it's always better to have tests so things don't regress.

Qiskit Optimization has tests of a similar method, to_ising(), in test_ising.py.

Relevant information for understanding what the encode() method is meant to do can be found in the QRACs section of the background material.

What is the expected enhancement?

A while back, @BryceFuller drafted a how-to guide on preparing and visualizing logical QRAC states. I'd like to refresh it and add it to the repository here.

Following the instructions in INSTALL.md , got an error on the line

$ pip install -e '.[notebook-dependencies]'

Which read:

ERROR: Could not find a version that satisfies the requirement cplex>=12.10 (from qrao[notebook-dependencies]) (from versions: none)
ERROR: No matching distribution found for cplex>=12.10

I am using Python version 3.10.4, but I believe the error is due to my laptops M1 chip (as it worked on my second laptop, which has the same OS/python version, but a different chip type)

Since cplex (to my knowledge) is only used as a check at the end of one tutorial, my solution was to just comment out the line in setup.py which makes cplex a dependency, namely

notebook_requirements = [
   # "cplex>=12.10",
    "tqdm[notebook]>=4.64",
]

However, I wanted to make the dev team aware of this issue going forward. Thanks

What is the expected enhancement?

In Qiskit Optimization, it is customary for an OptimizationAlgorithm to attempt to convert a problem to a QUBO if necessary, by invoking QuadraticProgramToQubo (see also the converter tutorial). However, QRAO requires the user to perform this conversion manually, in large part because the current explicit interface requires the problem to be in its final form before the QuantumRandomAccessOptimizer is even constructed (#9). Once this requirement is dropped, it would be nice to allow implicit conversion to QUBOs as well.

When closing this, we should also remove the corresponding usage note from the README.

What is the expected enhancement?

Currently, QuantumRandomAccessOptimizer.solve() performs some post-processing on the rounding results. However, if one calls solve_relaxed() and then performs rounding manually, there is no convenient way to perform this post-processing. We should add such a way.

Once complete, we should also update the second tutorial with the new method and remove the following text:

Note: in the future, we will expose functionality to easily translate the results obtained by manually rounding back to the solution of original problem. Currently, this happens automatically when calling QuantumRandomAccessOptimizer.solve(problem).

What is the expected enhancement?

Currently, a number of pylint checks are disabled throughout the code base. As we improve the code, we should either fix each check or disable it locally, in preparation for potential contribution to qiskit-optimization.

• fixme
• invalid-name
• too-few-public-methods
• missing-function-docstring
• protected-access (waiting on #7)
• redefined-outer-name
• no-member
• pointless-statement
• too-many-locals
• useless-super-delegation
• consider-using-f-string
• too-many-statements
• too-many-branches
• consider-using-enumerate
• duplicate-code
• docstring plugin tests (temporarily disabled in de3bf52)

Currently disabled within notebooks only

• wrong-import-order
• wrong-import-position (seems irrelevant, actually)
• line-too-long

What is the expected enhancement?

Currently, there is a build of the API reference at https://qiskit-community.github.io/prototype-qrao/apidocs/. However, the use of Sphinx could be improved. Most notably, some classes and functions are duplicated, e.g. on the encoding page. The duplication is presumably because those identifiers are included explicitly in the autosummary directive; however, if identifiers aren't included there, they end up not being clickable for additional detail (e.g., as is currently the case with EncodingCommutationVerifier). I've not been able to figure out Sphinx sufficiently to fix this.

What is the expected enhancement?

As the README currently says:

The Magic Rounding scheme is currently only compatible with the (3,1,p) QRAC for encoding classical binary variables onto qubits. [...] We plan to make Magic Rounding compatible with additional encoding options in the future.

Let's improve magic rounding to work regardless of whether max_vars_per_qubit is 1, 2, or 3 (i.e., with all available encodings).

Once this is complete, we can also remove the _encoding attribute from the RoundingContext and enable the protected-access pylint check throughout the code base.

What is the expected enhancement?

We've talked about renaming the following members of RoundingContext:

• trace_values isn't really a standard term (they are really Pauli expectation values)
• the circuit is really a state preparation circuit

What is the expected enhancement?

Once we have migrated to qiskit-ibm-provider (#15), the next step is to adopt and move toward the qiskit primitives. We use the VQE implementation from Terra, so the only thing to migrate in QRAO itself is the magic rounding scheme (and for that we will use the Sampler primitive).

We will probably begin by parameterizing the various basis rotations, so that a single circuit can be sent to the primitives, along with various parameter sets.

What is the expected behavior?

For example, correcting the probabilities by mthree can help improve the results on real-device backends.

What is the expected enhancement?

Currently, we have

but the parallel class in qiskit-optimization calls it min_eigen_solver_result. We've decided against renaming it in QRAO in this way because we feel it obscures the meaning of the relaxed Hamiltonian, but we might want to consider aliasing the property, such that either property works, for consistency with qiskit-optimization.