refactor(app, api): add comparison states support for both mounts in cal check#5583
Merged
Conversation
Prompt user to load the required tipracks into the correct slots of the deck before proceeding to
check the robot's calibration
Closes #5033
1 task
SyntaxColoring
added a commit
that referenced
this pull request
May 2, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 16, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 16, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 16, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 16, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 16, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 16, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 17, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 17, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 17, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it.
ddcc4
pushed a commit
that referenced
this pull request
May 17, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 17, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 17, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 17, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 17, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 17, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 19, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 19, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 19, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 20, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 20, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 22, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 23, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 24, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 24, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 29, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 29, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
ddcc4
pushed a commit
that referenced
this pull request
May 29, 2025
…oint equality (#18215) For a long time, `opentrons.types.Point` has overridden its `==` operator to return `True` if the two points are *numerically approximately* equal to each other, instead of *actually* equal. This was introduced in commit d13ed34 of PR #5583, possibly for the benefit of some calibration unit tests? I personally find this very surprising. If I do `a == b`, I strongly expect that to mean actual equality—if I wanted approximation, I would have used `isclose()`. In other words, I expect `point_a == point_b` to behave exactly like `(point_a.x == point_b.x) and (point_a.y == point_b.y) and (point_a.z == point_b.z)`. Also, it breaks [the rule that objects that compare equal must have the same hash value](https://docs.python.org/3/reference/datamodel.html#object.__hash__). ```python >>> a = Point() >>> b = Point(z=1e-20) >>> a == b True >>> hash(a) 3010437511937009226 >>> hash(b) 9180445109486892018 ``` So this PR restores strict equality checking. The old behavior is preserved as an explicit method, `point.elementwise_isclose(other)`, for the benefit of the few tests that were implicitly relying on it. (cherry picked from commit 4250aab)
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
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.
overview
Add support for difference vector comparisons for each point check in robot calibration flow. Also
add branching logic for different attached instruments cases and remove pipette id parameter from
triggers.
changelog
comparisonsByStepof the session statuspipette_id's around as parameters. Should probably deprecate entirely in next PRreview requests
Push branch to Robot and launch run app from branch. With the calibration check feature flag toggled "on". Proceed with the Check. The comparison screens are stubbed for now, but should have a "Continue" button that will proceed to the next check. Jogging outside of the threshold for tip pick up will lead to bad calibration data state (which doesn't have a view yet). Jogging outside of the threshold for any other check will add a record in redux under
comparisonsByStep->exceedsThreshold: true. This will be mapped to view logic in the next PR.risk assessment
Whole flow is still behind a feature flag, this doesn't touch anything exposed or shared.