quantum-computing

Currently task 1.3 (Validate inputs to QPE) is covered by two types of tests - Q# test TestAssertIsEigenstate_True that checks that the solution doesn't throw exceptions on inputs that are a valid unitary-eigenstate pair, and C# tests that check that the solution does throw exception on inputs that are not a valid un

Here are some examples:

• Root README is missing machine learning category of samples
• README in algorithms is missing repeat-until-success and sudoku-grover
• [README in diagnostics](https://github.com/microsoft/Quantum/blob/main/samples/diagnostics/RE

Environment

• Qiskit Terra version: 0.20
• Python version:
• Operating system:

What is happening?

In order to seed transpiler for a list of circuits a list of seeds is required. This is supported, but not mentioned anywhere:

https://github.com/Qiskit/qiskit-terra/blob/a296ca009bf440b5a2cb00f61b8221c6ce9aa044/qiskit/compiler/transpiler.py#L65

How can we reprodu

Is your feature request related to a use case or problem? Please describe.
Right now a lot of modules (in particular tests) are pretty free form with how they do imports. It's a good practice to import modules wherever possible.

bad:

from cirq.devices import GridQubit

good:

from cirq import devices

devices.GridQubit(whatever)

**Describe the soluti

Informations

• Qiskit version:
• Python version:
• Operating system:

What is the current behavior?

Each section in the tutorial page has its own index page showing up as an icon similar to the tutorials itself which is confusing.

Feature details

Currently, to use BasisEmbedding we have to pass a list with the bits [0,1,0,0] for example to put a PauliX gate in the second qubit. It would be nice to be able to pass an integer number like:

qml.BasisEmbedding(4, wires = range(4))

This result would be the same that:

qml.BasisEmbedding([0,1,0,0], wires = range(4))

because 0100 is t

To get this codebase up to standard, we need to add type hints. At the very least, perhaps we should start insisting that all new code has type hints added, but moreover we need to add typing to the code that currently exists.

This is a pretty large project, but luckily it can be done incrementally - I believe at this point it's a stretch goal for v1, if anyone wants to help it would be much ap

Describe the Issue!

Most of the functions in random_objects.py take an N input and an optional dims. Those input are redundant as the size (N) can be obtained from the dims. However the way they handle this inconsistent:

• Many functions, such as rand_super, rand_dm, check that the dims matches the size and raise an error if it doesn't.
• rand_dm_ginibre, rand_super_bcsz j

What is the expected enhancement?

The openQASM project should have release notes associated with each tagged release (see #321). These should contain a summary of all changes included in the prepared release (or the development branch). For ease (and distribution) of maintenance, we should consider using reno which has been used with success in Qiski

Describe the Issue

1. In section 2.4.3 on Controlled Rotations, the line "A controlled R_x(θ) could similarly be made using CNOT gates." seems incorrect.
2. I assume that the line claims that replacing R_y(θ/2) by R_x(θ/2) (similarly for the -θ case), in the circuit above, we would get a controlled R_x(θ). This is incorrect.
3. Passing |1> through q_0, we get X R_x(-θ/2) X R_x(θ/2)q_1, fo

Is your feature request related to a problem? Please describe.
Adding concrete examples to API documentation comments can help clarify how Q# functions and operations are to be used. For example, the documentation for Microsoft.Quantum.Arrays.ElementsAt lists how the function acts on a variety of arrays:

right now, absolute jumps are conflated in the label object here. I'd prefer we instead introduce a new object called absolute-program-location or something like that. (I don't want to use "address" only because it feels too dishonest.) If we do this, then we'd change patch-labels to not overwrite these label objects, and we'