Consistent behavior for service.run() job
When using service.run(), we see that the resulting output is consistent across providers:
IonQ
Honeywell
Calling service.run against different providers both return a CirqResult.
Inconsistent behavior for job.results() of existing job
However, when pulling back an existing job, we see inconsistent behavior:
For IonQ and Honeywell, job.results() returns the Raw Result format from the provider, rather than a consistent microsoft Result format that contains counts/probabilities.
In addition, it does not seem possible to get existing jobs back into the same format as if I were calling service.run(). For IonQ, I can use to_cirq_result to get back the result similar to when I called service.run().
If trying the same thing for honeywell, I get an error that dict object has no attribute to_cirq_result:
This means that even though honeywell service.run() returned a CirqResult, it is not possible to use similar method to get out a CirqResult from an existing job.
Consistent behavior for service.run() job
When using service.run(), we see that the resulting output is consistent across providers:
IonQ
Honeywell
Calling service.run against different providers both return a CirqResult.
Inconsistent behavior for job.results() of existing job
However, when pulling back an existing job, we see inconsistent behavior:
For IonQ and Honeywell, job.results() returns the Raw Result format from the provider, rather than a consistent microsoft Result format that contains counts/probabilities.
In addition, it does not seem possible to get existing jobs back into the same format as if I were calling service.run(). For IonQ, I can use to_cirq_result to get back the result similar to when I called service.run().
If trying the same thing for honeywell, I get an error that dict object has no attribute to_cirq_result:
This means that even though honeywell service.run() returned a CirqResult, it is not possible to use similar method to get out a CirqResult from an existing job.