Several katas could have better error messaging:

• Superposition : the test harness could log the actual state of the system after prep vs the expected state before asserting that they are the same (the change would add state prep and logging using DumpMachine to AssertEqualOnZeroState)
• BasicGates : a similar improvement, but a bit more extra code to write a unified test wrapper

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

It would be useful to be able to iterate over, or return a list of coefficients in PauliSumOp. At present, one has to dig into the details to construct the coefficients for each term. In particular, it requires multiplying

Is your feature request related to a use case or problem? Please describe.

Docstrings are a returning issue on PRs, it would be great if we could automate the feedback on them as well for Google style docstrings.

Describe the solution you'd like

Setup the docstyle and [docparams](ht

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

Running travis lint gives a bunch of warning. Like for instance, sudo : required is no longer needed, and Travis migrated to a new architecture. So the travis.yml file needs to be updated.

https://blog.travis-ci.com/2018-10-04-combining-linux-infrastructures

For example, pylint would have caught ProjectQ-Framework/ProjectQ#19 via an undefined variable warning.

What is the expected behavior?

Two independent but related VQE feature requests important for experiments on quantum hardware:

1. More shots on final cost-function evaluation
   There should be an option to increa

It would be nice to allow users to set a custom value for the tensorflow dtype if they are really pushing their simulations (and aware of the memory tradeoffs). This would be a very straightforward feature to add, most likely by adjusting backend_options to accept a dtype argument or something similar

See, e.g., the discussion below:

You could change this line https://github.com/XanaduAI

Implement a function to splice parsed-program objects together in a reasonable way.