Initialize Observable with string literals

[jordandsullivan]

Issue Description

Currently, the Observable class only accepts inputs of the type PauliString for the `paulisargument, which makes it rather lengthy to initialize anObservable` with many Pauli strings, as well as requiring an additional import. e.g. if I wanted to input a 4-qubit error detection code, the code would be as follows

from mitiq import Observable, PauliString

obs = Observable(PauliString("ZZZZ"), PauliString("XXII"), PauliString("IXXI"), PauliString("IIXX"))

Clearly there is a fair amount of repetition here, and this is a relatively short example.

Proposed Solution

It would be much quicker to allow users to define their operators with just string literals and then initialize the PauliString instance for them behind the scenes when instantiating the Observable. So the above example would be as follows on the user end:

from mitiq import Observable

obs = Observable("ZZZZ", "XXII", "IXXI", "IIXX")

We can still maintain backwards compatibility with the PauliString type by adding a check in the init for Observable which checks if the *paulis positional arguments are string literals or PauliStrings

Additional References

*Of course, given that this is Python, Observable does in fact accept any input as the paulis argument, but a string literal will fail when Observable tries to run any of the built-in PauliString methods.

[jordandsullivan]

It may also be nice to add the ability to initialize PauliString from string literals with coefficients, e.g. parsing "-2IXX" into a PauliString with .coeff attribute equal to 2.

[cosenal]

meta-note: instead of *, you can write an actual footnote in Github markdown, https://github.blog/changelog/2021-09-30-footnotes-now-supported-in-markdown-fields/ (I learned this from @natestemen)

content note: I am guessing the original intention of the Observable constructor was to accept other things than just Pauli strings. In that case, overloading it with string objects could make it ambiguous. One may end up passing string literals that are not Paulis, then the checks become complex.

typing note:

given that this is Python, Observable does in fact accept any input as the paulis argument

at runtime this is probably true, but it should fail mypy static checks

[jordandsullivan]

content note: I am guessing the original intention of the Observable constructor was to accept other things than just Pauli strings. In that case, overloading it with string objects could make it ambiguous.

Perhaps that was the intention, though I don't see any documentation to suggest it was. To quote first line of the User guide entry for Observable, "The mitiq.Observable class is a way to represent an observable as a linear combination of Pauli strings." This was added 3 years ago (https://github.com/unitaryfund/mitiq/commit/daab21ac24c1f0b23f4c42f4f6ddaf20749699ee), at the same time the class itself was introduced (https://github.com/unitaryfund/mitiq/commit/daab21ac24c1f0b23f4c42f4f6ddaf20749699ee).

One may end up passing string literals that are not Paulis, then the checks become complex.

The PauliString class already does checks like this, e.g. https://github.com/unitaryfund/mitiq/blob/2a41ad018fc0f8e82edceced9d4f5673aa65d1d4/mitiq/observable/pauli.py#L47-L60 I don't think it would be too much of a stretch to add a few lines for any additional checks needed.

given that this is Python, Observable does in fact accept any input as the paulis argument

at runtime this is probably true, but it should fail mypy static checks

Yes, but I am thinking from the user's perspective, not necessarily a mitiq developer's. A vanilla user would not necessarily be running Mypy.