Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Counts object #4501

Merged
merged 40 commits into from
Jul 7, 2020
Merged

Add Counts object #4501

merged 40 commits into from
Jul 7, 2020

Conversation

mtreinish
Copy link
Member

Summary

This commit adds a new class qiskit.result.Counts which is a dict
subclass for dealing with count results from experiment. It takes in a
counts dictionary with hexadecimal string keys and it's data is a binary
string, like the output of get_counts(). The idea is that this class
contains extra attributes about the execution and helper methods for
interacting with counts results. It can be used as a direct replacement
anywhere a counts dictionary was used previously. It is also now the
return type for qiskit.quantum_info.QuantumState.sample_counts().

This commit is part of the v2 providers interface work and will be a key
part of the new providers interface. This class is split out as a
seperate commit/PR from #4485.

Details and comments

This commit adds a new class qiskit.result.Counts which is a dict
subclass for dealing with count results from experiment. It takes in a
counts dictionary with hexadecimal string keys and it's data is a binary
string, like the output of get_counts(). The idea is that this class
contains extra attributes about the execution and helper methods for
interacting with counts results. It can be used as a direct replacment
anywhere a counts dictionary was used previously. It is also now the
return type for qiskit.quantum_info.QuantumState.sample_counts().

This commit is part of the v2 providers interface work and will be a key
part of the new providers interface. This class is split out as a
seperate commit/PR from Qiskit#4485.
@mtreinish mtreinish requested review from chriseclectic, ewinston and a team as code owners May 27, 2020 11:03
@mtreinish mtreinish mentioned this pull request May 27, 2020
6 tasks
Copy link
Member

@ajavadia ajavadia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you add tests for the two methods int_outcomes and most_frequent?

Also how does Counts object print? Does it need a __str__ or __repr__? Mainly because right now it is straightforward to see the counts and that behavior should persist.

releasenotes/notes/add-counts-class-7c75bd94d12a161a.yaml Outdated Show resolved Hide resolved
qiskit/result/exceptions.py Outdated Show resolved Hide resolved
@mtreinish
Copy link
Member Author

Oh, oops I wrote tests but forgot to add it to the commit. Fixed in: f433cbd

@mtreinish
Copy link
Member Author

As for the printing it will work exactly the same as the dict does from Result.get_counts() (assuming you pass in the classical register and memory slots as kwargs). There's no need to add a __str__ or __repr__ since this class is essentially just a dict that does the post-processing up front at object init and has a few extra helpers.

ajavadia
ajavadia previously approved these changes May 31, 2020
class Counts(dict):
"""A class to store a counts result from a circuit execution."""

def __init__(self, data, name=None, shots=None, time_taken=None,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we storing a lot of extra metadata in this container? There is already an ExperimentResult class for that so it seems to me Counts should just be the counts part of the result.

If I want to add additional return data types in the future (which I do!) like ExpectationValue, or Probabilities, there will be a lot of duplication of unneeded metadat.

In this case I think the only the counts needs is perhaps the creg_sizes so you can add whitespace to bitstrings during conversion, and memory_slots if you don't have creg_sizes so you know number of bits when converting from hex-format. Shots can be inferred from sum of dict elements, and time taken, name, and metadata seem unnecessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The metadata here is used in the v2 providers interface see #4485. In that model the results object will return an OrderedDict of Counts objects instead of a of ExperimentResult objects. So the metadata for an individual run will be stored here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I have issues with the V2 provider then, since it will not be suitable for simulators if there is no circuit level result object other than counts that can store different output data. I can leave those comments somewhere else.

@chriseclectic
Copy link
Member

Accidentally submitted before writing my main comment in the review. My main issue with this is if we are adding a class abstract why are we forcing ourselves to use the hex-string format when initializing. Regardless of what internal representation this class uses to store counts I think it should be able to be initialized from hex string counts, binary string counts, or integer key counts, and also apply conversion to any of these formats from whatever format it was initialized (you have one method for this for converting to int keys).

@chriseclectic
Copy link
Member

Another issue is that the counts from QuantumState aren't always bitstrings. They can be any dit string because they allow arbitrary dimension qudit subsystems. For example:

state = qi.Statevector([1, 1, 1, 1, 1, 1, 1, 1, 1], dims=[3,3]) / 3
state.sample_counts(1000)

will return {'00': 121, '01': 109, '02': 114, '10': 113, '11': 106, '12': 114, '20': 117, '21': 104, '22': 102}

@mtreinish
Copy link
Member Author

Accidentally submitted before writing my main comment in the review. My main issue with this is if we are adding a class abstract why are we forcing ourselves to use the hex-string format when initializing. Regardless of what internal representation this class uses to store counts I think it should be able to be initialized from hex string counts, binary string counts, or integer key counts, and also apply conversion to any of these formats from whatever format it was initialized (you have one method for this for converting to int keys).

This is a fair point I was thinking about doing this, but kept it simple. I'll work on adding the arbitrary conversions between the 3 forms. The default data format will still have to be the bitstrings for backwards compat with v2

Another issue is that the counts from QuantumState aren't always bitstrings. They can be any dit string because they allow arbitrary dimension qudit subsystems. For example:

state = qi.Statevector([1, 1, 1, 1, 1, 1, 1, 1, 1], dims=[3,3]) / 3
state.sample_counts(1000)

will return {'00': 121, '01': 109, '02': 114, '10': 113, '11': 106, '12': 114, '20': 117, '21': 104, '22': 102}

I actually think this will work as is today. Right now it calls result.postprocess.format_counts on the input which will only do anything if the string starts with 0x or creg_sizes and/or memory_slots are set. The helper methods will fail because Counts.hex_raw keys will be qudit strings instead of hex strings, but the Counts object will work fine as the dict is being used today. That being said I'll try to handle this in the next revision too.

@nonhermitian
Copy link
Contributor

I actually like the metadata. Much easier to access than from the Results. Also nice since direct access to the results is something we are moving away from.

This commit allows for the input key format for the data dict to be hex,
binary, or integers and use all the functionality as expected. It also
adds handling for dit strings which don't handle the hex or binary
output formats or allow for formating across registers.
mtreinish added 7 commits June 3, 2020 12:04
This commit removes the metadata support from the counts object. There
is some debate on wheter we want to enable support for attaching
arbitrary key value metadata to a Counts object or not. Until that
debate is settled this commit removes it from the object to unblock
progress. It will be simple to add in a backwards compat manner if it
decided that we want to enable this in the future.
@ajavadia ajavadia added this to the 0.15 milestone Jun 18, 2020
Copy link
Member

@chriseclectic chriseclectic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest removing all the non-count related metadata from the Counts class in this PR until we discuss more under the V2 provider, other than that this looks good. This way we can merge it as a replacement for the current dict returned by get_counts until other things are agreed on.

qiskit/result/counts.py Outdated Show resolved Hide resolved
qiskit/result/counts.py Show resolved Hide resolved
qiskit/result/counts.py Outdated Show resolved Hide resolved
qiskit/result/counts.py Outdated Show resolved Hide resolved
@mtreinish mtreinish requested a review from chriseclectic June 29, 2020 11:52
@kdk kdk added the automerge label Jul 7, 2020
@mergify mergify bot merged commit d954194 into Qiskit:master Jul 7, 2020
@mtreinish mtreinish deleted the add-counts-object branch July 12, 2020 14:33
faisaldebouni pushed a commit to faisaldebouni/qiskit-terra that referenced this pull request Aug 5, 2020
* Add Counts object

This commit adds a new class qiskit.result.Counts which is a dict
subclass for dealing with count results from experiment. It takes in a
counts dictionary with hexadecimal string keys and it's data is a binary
string, like the output of get_counts(). The idea is that this class
contains extra attributes about the execution and helper methods for
interacting with counts results. It can be used as a direct replacment
anywhere a counts dictionary was used previously. It is also now the
return type for qiskit.quantum_info.QuantumState.sample_counts().

This commit is part of the v2 providers interface work and will be a key
part of the new providers interface. This class is split out as a
seperate commit/PR from Qiskit#4485.

* Fix docs build

* Fix lint

* Add missing test file

* Switch custom exception class to QiskitError

* Cleanup release note

* Add comment about dict subclassing

* Tweak comment wording slightly

* Add support for int and binary input keys and handle qudits

This commit allows for the input key format for the data dict to be hex,
binary, or integers and use all the functionality as expected. It also
adds handling for dit strings which don't handle the hex or binary
output formats or allow for formating across registers.

* Fix tests

* Fix lint

* Handle 0b prefixed binary strings

* Update init docs

* Fix docs again

* Add tests for 0b prefixed input

* Remove metadata from Counts object

This commit removes the metadata support from the counts object. There
is some debate on wheter we want to enable support for attaching
arbitrary key value metadata to a Counts object or not. Until that
debate is settled this commit removes it from the object to unblock
progress. It will be simple to add in a backwards compat manner if it
decided that we want to enable this in the future.

* Use Counts instead of dict for Results.get_counts() output

* Remove other circuit level metadata

* Update results to not include removed metadata

* Fix tests

* Really remove metadata from class

Co-authored-by: Luciano Bello <luciano.bello@ibm.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
@mtreinish mtreinish added the Changelog: New Feature Include in the "Added" section of the changelog label Aug 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: New Feature Include in the "Added" section of the changelog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants