Bugfix for Germ Selection Line Labels and Instrument Specifier Type Error Bug

[pcwysoc]

Bugfix for #507 and instrument specifier type error bug.

[coreyostrove]

Minor issue with an errant print statement, and a question for you on the conventions surrounding the change in processorspec.py. See comments below.

[coreyostrove]

Is the convention here that the keys of nonstd_instruments are always tuples? If other hashable types are allowed this should be written so as to accept those options too. One way to do so would be to use the get method for dictionaries.

[coreyostrove]

Actually, I can answer this. I took a look at the unit test that was failing on this branch and it confirms that there was and intention for these to also have the option for string valued keys. See here.

We could rewrite this to account for both options at the level of this method, but the thing is it should be necessary to cast the name to a tuple here. If you're fixing this because you ran into a problem here it suggests to me that something upstream of this method is using malformed inputs, or has inadvertently hardcoded in the expectation that this is always a string (and not a tuple). My preference would be to track this down, but if folks would rather patch this to accept both strings and tuples (casting if needed) to get this working I won't push back too hard.

[pcwysoc]

@coreyostrove What would a string valued key look like? The tuple valued key is ('Iz', 'Q0') for example. Currently, the problem is cropping up from processor_spec.instrument_names returns (['Iz', 'Q0'],) which is neither of the acceptable formats. This ultimately breaks QILGST.

[coreyostrove]

Hey @pcwysoc and anyone else tracking this PR, I've just pushed some changes to this branch unceremoniously hijacking it with some scope creep.

The quest to answer the innocuous seeming question you posed above "What would a string valued key look like?" brought to bear the fact that this part of the code regarding the expected structure/formats for nonstandard operation specifiers (i.e. the contents of things like nonstd_preps, nonstd_povms, etc., was almost entirely undocumented, and so to answer that question required reading and reverse engineering a bunch of model constructor code. Since while I was in there the sunk cost was already paid and I've been frustrated by the lack of documentation before I've gone ahead and written up detailed documentation for the processor spec classes explaining in detail exactly what the specifier formats for preps, POVM and instruments that are presently supported for the code are and how they work (the gate specifiers were already reasonably well documented, so that hasn't changed). There were a whole bunch of options supported I had no idea existed.

I've also made some more substantive changes as well, introducing some additional (previously unsupported) specifier options to improve the consistency across the various nonstandard operations. E.g. Previously string-based effect specifiers (which I didn't know existed before this exercise) only supported strings of the form "E" where is some integer to be parsed into the correctly based number representing a particular standard basis state. But for preps we also supported another format for such strings where we specify the bitstring directly. This has been updated so that effects and preps have similar behavior. There are other changes along these lines that have been made.

I can also now fairly confidently answer your question:

What would a string valued key look like? The tuple valued key is ('Iz', 'Q0') for example. Currently, the problem is cropping up from processor_spec.instrument_names returns (['Iz', 'Q0'],) which is neither of the acceptable formats. This ultimately breaks QILGST.

The use of tuples for instrument names or as keys in the nonstd_instruments dictionary for a processor spec doesn't look to be an intended usage/convention, so actually these keys should likely always be strings. I suspect that the use of tuples as keys was identified by someone at some point as a hack which helped force target qubit labels for instruments into models constructed from instrument containing processor specs, circumventing the fact that availability resolution isn't currently implemented for instruments. (This is the line of code being exploited to make this hack work in case you're curious

pyGSTi/pygsti/models/modelconstruction.py

Line 883 in 551b157

key = _label.Label(instrument_name, inds)

).

Unfortunately what this means is that in my opinion the only proper way to fix this (without nested layers of duct-tape) is to pull the trigger on implementing availability resolution support for instruments (obviating the need for the tuple key hack). That'll probably be a pain, but fwiw we'd already identified this as something which would eventually need to happen #417.