-
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
Bound ParameterExpression
s do not match the hash of an equal object of a numeric type
#12487
Labels
bug
Something isn't working
Comments
wshanks
added a commit
to wshanks/qiskit-terra
that referenced
this issue
May 31, 2024
If a `ParameterExpression` has no unbound parameters, the underlying bound value can be hashed instead of the tuple that accounts for the symbolic expression. Doing this allows for the `ParameterExpression` to match the hash for the numeric value it compares equal to. Closes Qiskit#12487
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 11, 2024
* Use hash of numeric value for bound parameter expressions If a `ParameterExpression` has no unbound parameters, the underlying bound value can be hashed instead of the tuple that accounts for the symbolic expression. Doing this allows for the `ParameterExpression` to match the hash for the numeric value it compares equal to. Closes #12487 * Add release note
mergify bot
pushed a commit
that referenced
this issue
Jun 11, 2024
* Use hash of numeric value for bound parameter expressions If a `ParameterExpression` has no unbound parameters, the underlying bound value can be hashed instead of the tuple that accounts for the symbolic expression. Doing this allows for the `ParameterExpression` to match the hash for the numeric value it compares equal to. Closes #12487 * Add release note (cherry picked from commit bc685d3)
mergify bot
pushed a commit
that referenced
this issue
Jun 11, 2024
* Use hash of numeric value for bound parameter expressions If a `ParameterExpression` has no unbound parameters, the underlying bound value can be hashed instead of the tuple that accounts for the symbolic expression. Doing this allows for the `ParameterExpression` to match the hash for the numeric value it compares equal to. Closes #12487 * Add release note (cherry picked from commit bc685d3)
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 12, 2024
…12548) * Use hash of numeric value for bound parameter expressions If a `ParameterExpression` has no unbound parameters, the underlying bound value can be hashed instead of the tuple that accounts for the symbolic expression. Doing this allows for the `ParameterExpression` to match the hash for the numeric value it compares equal to. Closes #12487 * Add release note (cherry picked from commit bc685d3) Co-authored-by: Will Shanks <[email protected]>
Procatv
pushed a commit
to Procatv/qiskit-terra-catherines
that referenced
this issue
Aug 1, 2024
* Use hash of numeric value for bound parameter expressions If a `ParameterExpression` has no unbound parameters, the underlying bound value can be hashed instead of the tuple that accounts for the symbolic expression. Doing this allows for the `ParameterExpression` to match the hash for the numeric value it compares equal to. Closes Qiskit#12487 * Add release note
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
What is happening?
When all the parameters in a
ParameterExpression
are bound, it becomes equal to afloat
,int
, orcomplex
. However, it still uses its own hashing algorithm, so it does not hash to the same value as the numeric type. The Python data model documents that objects that compare equal should hash to the same value.How can we reproduce the issue?
What should happen?
As much as possible, the Python data model should be followed. At some points in the parameter handling code, bound
ParameterExpression
s are eagerly cast tofloat
. For example, thefloat(p)
here:qiskit/qiskit/transpiler/passes/scheduling/scheduling/base_scheduler.py
Line 71 in 26886a1
I think this is done to avoid a bound
p
failing the lookup if the calibrations dict was keyed with a plainfloat
. It would be preferable not to have to deal with type casting in these cases.Any suggestions?
No response
The text was updated successfully, but these errors were encountered: