quantum

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

Include a script that can generate weekly status reports to dev's leadership. The report should have enough buzzwords to make leadership feel as if progress is being made without providing any specific detail that defines said progress.

Feature details

Due to the similarity, it is easy to confuse qml.X and qml.PauliX, especially since other methods of specifying circuits, e.g., QASM, use x for PauliX. But if a user uses qml.X in their circuit on a qubit device, nothing happens to inform them that the incorrect operation is being used:

@qml.qnode(dev)
def circ():
    qml.PauliX(wires=0)
    qml.Hada

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

Most documentation comments in the compiler only use the <summary> tag. For short comments, this is fine, but in many cases the summary is several paragraphs long and would be easier to read if it used standard documentation tags to structure the information. This is especially important for exceptions - exceptions mentioned in the <summary> tag are easy to miss, whereas the special `<exceptio

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:

(Up for grabs for anyone who wants to do this)

Docpages generated for flax modules such as our models (RBM, RBMSymm, DenseSymm) are somehow... confused.
That's because Flax modules have a lot of methods scattered around and the attributes get put a bit everywhere.

Moreover, attributes of the model/layer itself are mixed with attributes common to all flax modules that are not really relevan

In addition to the current acceptable arguments for Q.Matrix, it ought to accept a Template literal (Template string) as a solo argument to make it trivially easy for something like this:

var m = new Q.Matrix(`
    1 2 3 4
    5 6 7 8`)

This makes the task of creating arbitrary matrices much more human readable than passing nested Arrays, or even just a series of Arrays.

In the path https://github.com/microsoft/qsharp-runtime/tree/main/src/Simulation/Native there's a number of binary files whose name ends with _test. Those are test executables (in ELF format, likely for Linux) generated during the build.
We don't need them in the repo.

Information

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

Conversation in slack at #metal.
https://qiskit.slack.com/archives/C01R8KP5WP7/p1638275287214400

What is the current behavior?

It a