Handle huge integers in OpenQASM 2 expression evaluator #12140
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This modifies the expression evaluator to directly parse the backing string data of an integer token in a floating-point context, which lets us handle numbers that would otherwise overflow a `usize`. It's possible for this to be totally valid, if, for example, the integer is a multiple of some very large power of two that doesn't overflow a double-precision float. We already needed to immediately cast the integer to a float, so this is just a more accurate way of doing the evaluation, and doesn't affect when we use integers in other contexts.
jakelishman
added
stable backport potential
|
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 8646868413Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
kevinhartman
reviewed
Apr 9, 2024
kevinhartman
approved these changes
May 14, 2024
mergify bot
pushed a commit
that referenced
this pull request
May 14, 2024
* Handle huge integers in OpenQASM 2 expression evaluator This modifies the expression evaluator to directly parse the backing string data of an integer token in a floating-point context, which lets us handle numbers that would otherwise overflow a `usize`. It's possible for this to be totally valid, if, for example, the integer is a multiple of some very large power of two that doesn't overflow a double-precision float. We already needed to immediately cast the integer to a float, so this is just a more accurate way of doing the evaluation, and doesn't affect when we use integers in other contexts. * Clarify int/float split (cherry picked from commit fe69594)
|
@Mergifyio backport stable/0.46 |
✅ Backports have been created
|
mergify bot
pushed a commit
that referenced
this pull request
May 14, 2024
* Handle huge integers in OpenQASM 2 expression evaluator This modifies the expression evaluator to directly parse the backing string data of an integer token in a floating-point context, which lets us handle numbers that would otherwise overflow a `usize`. It's possible for this to be totally valid, if, for example, the integer is a multiple of some very large power of two that doesn't overflow a double-precision float. We already needed to immediately cast the integer to a float, so this is just a more accurate way of doing the evaluation, and doesn't affect when we use integers in other contexts. * Clarify int/float split (cherry picked from commit fe69594)
github-merge-queue bot
pushed a commit
that referenced
this pull request
May 14, 2024
) * Handle huge integers in OpenQASM 2 expression evaluator This modifies the expression evaluator to directly parse the backing string data of an integer token in a floating-point context, which lets us handle numbers that would otherwise overflow a `usize`. It's possible for this to be totally valid, if, for example, the integer is a multiple of some very large power of two that doesn't overflow a double-precision float. We already needed to immediately cast the integer to a float, so this is just a more accurate way of doing the evaluation, and doesn't affect when we use integers in other contexts. * Clarify int/float split (cherry picked from commit fe69594) Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
github-merge-queue bot
pushed a commit
that referenced
this pull request
May 14, 2024
) * Handle huge integers in OpenQASM 2 expression evaluator This modifies the expression evaluator to directly parse the backing string data of an integer token in a floating-point context, which lets us handle numbers that would otherwise overflow a `usize`. It's possible for this to be totally valid, if, for example, the integer is a multiple of some very large power of two that doesn't overflow a double-precision float. We already needed to immediately cast the integer to a float, so this is just a more accurate way of doing the evaluation, and doesn't affect when we use integers in other contexts. * Clarify int/float split (cherry picked from commit fe69594) Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
ElePT
pushed a commit
to ElePT/qiskit
that referenced
this pull request
May 31, 2024
* Handle huge integers in OpenQASM 2 expression evaluator This modifies the expression evaluator to directly parse the backing string data of an integer token in a floating-point context, which lets us handle numbers that would otherwise overflow a `usize`. It's possible for this to be totally valid, if, for example, the integer is a multiple of some very large power of two that doesn't overflow a double-precision float. We already needed to immediately cast the integer to a float, so this is just a more accurate way of doing the evaluation, and doesn't affect when we use integers in other contexts. * Clarify int/float split
jakelishman
added a commit
to jakelishman/qiskit-terra
that referenced
this pull request
Jul 15, 2024
We fixed handling of giant integers in gate expression positions Qiskitgh-12140, and this commit fixes the handling in conditionals. Unfortunately, this means pulling in big-int handling properly; the integers simply _are_ bigints, and we're not immediately converting them into something else. The need to support this may influence how the Rust-space data models of `QuantumCircuit` evolve.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jul 30, 2024
* Fix parsing of huge OpenQASM 2 conditionals We fixed handling of giant integers in gate expression positions gh-12140, and this commit fixes the handling in conditionals. Unfortunately, this means pulling in big-int handling properly; the integers simply _are_ bigints, and we're not immediately converting them into something else. The need to support this may influence how the Rust-space data models of `QuantumCircuit` evolve. * Move `num-bigint` dependency to workspace
mergify bot
pushed a commit
that referenced
this pull request
Jul 30, 2024
* Fix parsing of huge OpenQASM 2 conditionals We fixed handling of giant integers in gate expression positions gh-12140, and this commit fixes the handling in conditionals. Unfortunately, this means pulling in big-int handling properly; the integers simply _are_ bigints, and we're not immediately converting them into something else. The need to support this may influence how the Rust-space data models of `QuantumCircuit` evolve. * Move `num-bigint` dependency to workspace (cherry picked from commit 85f9860) # Conflicts: # Cargo.toml # crates/accelerate/Cargo.toml
mergify bot
pushed a commit
that referenced
this pull request
Jul 30, 2024
* Fix parsing of huge OpenQASM 2 conditionals We fixed handling of giant integers in gate expression positions gh-12140, and this commit fixes the handling in conditionals. Unfortunately, this means pulling in big-int handling properly; the integers simply _are_ bigints, and we're not immediately converting them into something else. The need to support this may influence how the Rust-space data models of `QuantumCircuit` evolve. * Move `num-bigint` dependency to workspace (cherry picked from commit 85f9860)
This was referenced Jul 30, 2024
jakelishman
added a commit
that referenced
this pull request
Jul 30, 2024
* Fix parsing of huge OpenQASM 2 conditionals We fixed handling of giant integers in gate expression positions gh-12140, and this commit fixes the handling in conditionals. Unfortunately, this means pulling in big-int handling properly; the integers simply _are_ bigints, and we're not immediately converting them into something else. The need to support this may influence how the Rust-space data models of `QuantumCircuit` evolve. * Move `num-bigint` dependency to workspace (cherry picked from commit 85f9860)
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jul 30, 2024
* Fix parsing of huge OpenQASM 2 conditionals We fixed handling of giant integers in gate expression positions gh-12140, and this commit fixes the handling in conditionals. Unfortunately, this means pulling in big-int handling properly; the integers simply _are_ bigints, and we're not immediately converting them into something else. The need to support this may influence how the Rust-space data models of `QuantumCircuit` evolve. * Move `num-bigint` dependency to workspace (cherry picked from commit 85f9860) Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jul 30, 2024
* Fix parsing of huge OpenQASM 2 conditionals We fixed handling of giant integers in gate expression positions gh-12140, and this commit fixes the handling in conditionals. Unfortunately, this means pulling in big-int handling properly; the integers simply _are_ bigints, and we're not immediately converting them into something else. The need to support this may influence how the Rust-space data models of `QuantumCircuit` evolve. * Move `num-bigint` dependency to workspace (cherry picked from commit 85f9860) Co-authored-by: Jake Lishman <jake.lishman@ibm.com>
Procatv
pushed a commit
to Procatv/qiskit-terra-catherines
that referenced
this pull request
Aug 1, 2024
* Fix parsing of huge OpenQASM 2 conditionals We fixed handling of giant integers in gate expression positions Qiskitgh-12140, and this commit fixes the handling in conditionals. Unfortunately, this means pulling in big-int handling properly; the integers simply _are_ bigints, and we're not immediately converting them into something else. The need to support this may influence how the Rust-space data models of `QuantumCircuit` evolve. * Move `num-bigint` dependency to workspace
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This modifies the expression evaluator to directly parse the backing string data of an integer token in a floating-point context, which lets us handle numbers that would otherwise overflow a
usize. It's possible for this to be totally valid, if, for example, the integer is a multiple of some very large power of two that doesn't overflow a double-precision float.We already needed to immediately cast the integer to a float, so this is just a more accurate way of doing the evaluation, and doesn't affect when we use integers in other contexts.
Details and comments
Fix #11561