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

Does existing documentation need to be updated with new content?

• Which files need to be updated?

https://qiskit.org/documentation/stubs/qiskit.compiler.transpile.html
https://qiskit.org/documentation/stubs/qiskit.transpiler.CouplingMap.html

• What content needs to be updated or replaced? (You can copy and paste)

https://qiskit.org/documentation/stubs/qiskit.compiler.transpile.htm

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

The qml.kernels.utils.py file contains the utility functions to compute the square kernel matrix of a training set as well as the kernel matrix between training and test data. There are some aspects that could be updated though:

• These functions are not compatible with all frameworks, for example the usage of np.array in these functions prohibits using them with Torch or

Problem Description

Currently the documentation PDF has to be built locally for each release.

Proposed Solution

Build the documentation in a GitHub action either for each push or when deploying a release.

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.