Update json/dict response for execute

[oschusler]

When calling qx.execute() a json file is generated. At the same time, content is printed to stdout. There is a mismatch between the two; stdout outputs the complex amplitudes and probabilities, while the json only contains the probabilities.

Proposal

The return object should be updated to also contain the complex amplitudes. This object could have the following structure, with only the state added to the current object:

{
    "info": {
        "shots_requested": 1000,
        "shots_done": 1000
    },
    "results": {
        "00": 0.5000,
        "11": 0.5000
    },
    "state": {
        "00": {
            "real": 0.707107,
            "imag": 0
        },
        "11": {
            "real": 0.707107,
            "imag": 0
        }
    }
}

Additional request

Furthermore, output is currently output to a json file. For our system we have to read the file and parse it (with a library, but still). Since we call a python function we would expect this function to return the same content as the json file.

This snippet would give the same output as the code block above.

result = qx.execute()
pprint.pprint(result)

[pablolh]

Hi Olaf,

I remember that when we discussed with Richard, we came to the requirement that the JSON format had to be identical between the simulator and the hardware backends (which have no knowledge of the quantum state). Has that changed?
The nice thing with probabilities there is that the output format matches exactly the output of the "multiple shots" version as well as that of the hardware backends.

I am happy to add the quantum state complex numbers to the JSON output, but shouldn't that only be when we do a single shot? Cause in case of multiple runs it would only be the state at the end of the last shot. Think about non-deterministic algos, then your state is non-deterministic.

Concerning the output of qx.execute(), I totally agree. I need to check what SWIG can do to output something nice in Python. Will come back to you on that one.

[oschusler]

Hi Pablo,

Thanks for the swift response.

The requirement that the output should have the same format (e.g. keys or structure) has not changed. However, in the case of a simulator, additional data is of course possible. In the current setup we already have the option to save the qubit state in the API data model (not sure if we offer it to the end user, though). In the new setup, we would actually also like to have access to it. At the moment, we can only access it via the stdout output, which also means that both outputs differ from each other.

With regard to the actual meaning of the output, that's a bit beyond me. During the meeting I had with Richard today, he said that we could still use it for circuits with a measure. However, that's something I don't know. If you want to know for sure, you should ask him.

[pablolh]

I have a PR ready #120
But still one question
To me it makes more sense to then have "results" json section always contain measurement register averaging (even in the case of a single run) and "state" also contain norms, that is

    "state": {
        "00": {
            "real": 0.707107,
            "imag": 0,
            "norm": 0.500000
        },
        "11": {
            "real": 0.707107,
            "imag": 0,
            "norm": 0.500000
        }
    }

What do you think?

The reason is that since we always output the state, it doesn't make sense to distinguish anymore the case of a single run (outputing complex norms in "results") and the case of multiple runs (outputing measurement register averaging in "results").
Probabilities in the case of a single run would then be obtained by looking into the "state" section.
So in all cases, "results" is always something that you can experimentally obtain.

[oschusler]

Lets say, you have a circuit without an explicit measure at the end. Would this mean that you don't get the actual probablities (that's in state)? In the case of a single measurement, you would always get 100% for that state (like the example below), right?

{
    "results": {
        "00": 1.0000
    }
}

If that is what you mean, it would mean that we would have to make a distinction between tags based on deterministic and non-deterministic circuits. I would still very mich like to avoid this. In principle we would like one section with probabilities (either measured, or determined from qubit state), and one with more detailed information (like complex amplitudes).

[pablolh]

I don't have strong opinion on this. In #120 the results section contains probabilities when running a single time, and measurement register averaging when running 2+ times. So if you're happy with it, you can go ahead and approve.

[oschusler]

I've approved the PR. Thanks!