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

What should we add?

A Google search for "qiskit barrier" leads one to its entry in the API reference as the first hit. Unfortunately, this page contains only a circular definition, and does not even explain what a barrier does:

Barrier instruction.

Create new

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

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.

As noted in #44, the qasm parser currently doesn't understand the ry gate. By looking at the definition of this gate in the Qiskit source, it should be relatively straightforward to implement support for this gate.