-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Fix process-based non-determinism in SparsePauliOp.to_matrix
#13439
Fix process-based non-determinism in SparsePauliOp.to_matrix
#13439
Conversation
The simplification step of the summed Pauli terms in `SparsePauliOp.to_matrix` had introduced a non-determinism via hash-map iteration. In practice, the base hash seed was set per initialisation of the extension module, then stayed the same. This is hard to detect from within tests, but caused unexpected numerical behaviour on different invocations of the same script.
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 11840492573Details
💛 - Coveralls |
@@ -298,7 +299,7 @@ impl MatrixCompressedPaulis { | |||
/// explicitly stored operations, if there are duplicates. After the summation, any terms that | |||
/// have become zero are dropped. | |||
pub fn combine(&mut self) { | |||
let mut hash_table = HashMap::<(u64, u64), Complex64>::with_capacity(self.coeffs.len()); | |||
let mut hash_table = IndexMap::<(u64, u64), Complex64>::with_capacity(self.coeffs.len()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to use ahash for the hasher here so the lookup performance is basically the same as HashMap
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should have no meaningful effect on the whole algorithm's performance because this bit is immeasurable compared to the cost of constructing the matrix, but the only reason I didn't do it is because I forgot.
My kids are awake now, so if somebody wanted to push up that change in time to get this into 1.3.0, it's fine by me - I won't have time til tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 23ba5f4 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I don't feel strongly that this needs a test given the circumstances.
If anyone disagrees, we can add one in a separate PR.
* Fix process-based non-determinism in `SparsePauliOp.to_matrix` The simplification step of the summed Pauli terms in `SparsePauliOp.to_matrix` had introduced a non-determinism via hash-map iteration. In practice, the base hash seed was set per initialisation of the extension module, then stayed the same. This is hard to detect from within tests, but caused unexpected numerical behaviour on different invocations of the same script. * Use ahash::RandomState --------- Co-authored-by: Kevin Hartman <[email protected]> (cherry picked from commit 74b32c9)
… (#13440) * Fix process-based non-determinism in `SparsePauliOp.to_matrix` The simplification step of the summed Pauli terms in `SparsePauliOp.to_matrix` had introduced a non-determinism via hash-map iteration. In practice, the base hash seed was set per initialisation of the extension module, then stayed the same. This is hard to detect from within tests, but caused unexpected numerical behaviour on different invocations of the same script. * Use ahash::RandomState --------- Co-authored-by: Kevin Hartman <[email protected]> (cherry picked from commit 74b32c9) Co-authored-by: Jake Lishman <[email protected]>
Summary
The simplification step of the summed Pauli terms in
SparsePauliOp.to_matrix
had introduced a non-determinism via hash-map iteration. In practice, the base hash seed was set per initialisation of the extension module, then stayed the same. This is hard to detect from within tests, but caused unexpected numerical behaviour on different invocations of the same script.Details and comments
This fixes the bug part of #13413, but doesn't address the feature request. It should be eligible for backport to either 1.3.0 or 1.3.1, depending on whether there's time to make 1.3.0.
Writing a test that would exercise this would be pretty complex, so I haven't done it. I can if we feel strongly about it - we'd likely embed a little script into a test and spawn some
sys.executable
instances to run it and check the outputs all matched bit-for-bit.