Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First attempt at fixing #1007, with potential fixes/benefits for #1008
X0, however this functionality and some of the other requests (ie. Improve error messaging around Pauli string parsing #1008) were also symptoms of the fact that regex was being used, rather than a fully-fledged parser.larklibrary was already being used elsewhere in this project and was in the requirements file, so I've replaced the regexp usage with a custom lark parser (defined as a short python string rather than a separate file, just for brevity) to take care of converting the Pauli strings to the correct python objects.0.7X1to represent0.7 * X1, which was one of the 'expected fail' unit-tests previously (now moved to 'expected pass'), as well as allowing justX0/X1as Pauli short strings (also moved from expected fail to expected pass).from_custom_strmethod forPauliTermhas been entirely replaced by the new parser, but I stopped short of replacing thefrom_custom_stronPauliSum, because the API currently expects a list ofPauliTermobjects to be summed; this behaviour is now usable with the new parsing code, but it would be a wider-ranging API change to use the parser instead of the one remaining regex inPauliSum, because of the change from a list of terms to a single term, which I decided was not an appropriate decision to make in this PR.0.5X1(ie. coefficient first, operator second), but we don't want to supportX10.5(ie. coefficient second) because the operator has a numeric value as the last digit, so this is obviously ambiguous. As a result the lark parser has a slightly larger than expected?pauli_term:section, rather than supporting all permutations of operators and coefficients up front.PauliTerm/PauliSumclasses, as well as checking expected error messages for bad inputs.Checklist
flake8][flake8] conventions.