Introduce int_oo (#127693) #3936
Closed
+5
−4
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
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/3936
Note: Links to docs will display an error until the docs builds have been completed. ❌ 1 New FailureAs of commit 928bbd0 with merge base 88e9737 ( NEW FAILURE - The following job has failed:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D58394154 |
facebook-github-bot
pushed a commit
that referenced
this pull request
Jun 11, 2024
Summary: In a previous life, we used sympy.oo to represent the lower/upper bounds of integer ranges. Later, we changed this to be sys.maxsize - 1 for a few reasons: (1) sometimes we do tests on a value being exactly sys.maxsize, and we wanted to avoid a data dependent guard in this case, (2) sympy.oo corresponds to floating point infinity, so you get incorrect types for value ranges with oo, and (3) you can do slightly better reasoning if you assume that input sizes fall within representable 64-bit integer range. After working in the sys.maxsize regime for a bit, I've concluded that this was actually a bad idea. Specifically, the problem is that you end up with sys.maxsize in your upper bound, and then whenever you do any sort of size-increasing computation like size * 2, you end up with 2 * sys.maxsize, and you end up doing a ton of arbitrary precision int computation that is totally unnecessary. A symbolic bound is better. But especially after #126905, we can't go back to using sympy.oo, because that advertises that it's not an integer, and now your ValueRanges is typed incorrectly. So what do we do? We define a new numeric constant `int_oo`, which is like `sympy.oo` but it advertises `is_integer`. **test/test_sympy_utils.py** describes some basic properties of the number, and **torch/utils/_sympy/numbers.py** has the actual implementation. The rest of the changes of the PR are working out the implications of this change. I'll give more commentary as inline comments. Fixes pytorch/pytorch#127396 Signed-off-by: Edward Z. Yang <ezyang@meta.com> X-link: pytorch/pytorch#127693 Approved by: https://github.com/lezcano ghstack dependencies: #126905 bypass-github-export-checks pushed new commits to forward fix error Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/9cab5987bdeb66df8efbc581b3469bfe300e168c Differential Revision: D58394154 Pulled By: clee2000
facebook-github-bot
force-pushed
the
export-D58394154
branch
from
7e006b5
to
7544428
Compare
|
This pull request was exported from Phabricator. Differential Revision: D58394154 |
facebook-github-bot
pushed a commit
that referenced
this pull request
Jun 11, 2024
Summary: In a previous life, we used sympy.oo to represent the lower/upper bounds of integer ranges. Later, we changed this to be sys.maxsize - 1 for a few reasons: (1) sometimes we do tests on a value being exactly sys.maxsize, and we wanted to avoid a data dependent guard in this case, (2) sympy.oo corresponds to floating point infinity, so you get incorrect types for value ranges with oo, and (3) you can do slightly better reasoning if you assume that input sizes fall within representable 64-bit integer range. After working in the sys.maxsize regime for a bit, I've concluded that this was actually a bad idea. Specifically, the problem is that you end up with sys.maxsize in your upper bound, and then whenever you do any sort of size-increasing computation like size * 2, you end up with 2 * sys.maxsize, and you end up doing a ton of arbitrary precision int computation that is totally unnecessary. A symbolic bound is better. But especially after #126905, we can't go back to using sympy.oo, because that advertises that it's not an integer, and now your ValueRanges is typed incorrectly. So what do we do? We define a new numeric constant `int_oo`, which is like `sympy.oo` but it advertises `is_integer`. **test/test_sympy_utils.py** describes some basic properties of the number, and **torch/utils/_sympy/numbers.py** has the actual implementation. The rest of the changes of the PR are working out the implications of this change. I'll give more commentary as inline comments. Fixes pytorch/pytorch#127396 Signed-off-by: Edward Z. Yang <ezyang@meta.com> X-link: pytorch/pytorch#127693 Approved by: https://github.com/lezcano ghstack dependencies: #126905 bypass-github-export-checks pushed new commits to forward fix error Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/9cab5987bdeb66df8efbc581b3469bfe300e168c Differential Revision: D58394154 Pulled By: clee2000
facebook-github-bot
force-pushed
the
export-D58394154
branch
from
7544428
to
409fd7e
Compare
|
This pull request was exported from Phabricator. Differential Revision: D58394154 |
Summary: In a previous life, we used sympy.oo to represent the lower/upper bounds of integer ranges. Later, we changed this to be sys.maxsize - 1 for a few reasons: (1) sometimes we do tests on a value being exactly sys.maxsize, and we wanted to avoid a data dependent guard in this case, (2) sympy.oo corresponds to floating point infinity, so you get incorrect types for value ranges with oo, and (3) you can do slightly better reasoning if you assume that input sizes fall within representable 64-bit integer range. After working in the sys.maxsize regime for a bit, I've concluded that this was actually a bad idea. Specifically, the problem is that you end up with sys.maxsize in your upper bound, and then whenever you do any sort of size-increasing computation like size * 2, you end up with 2 * sys.maxsize, and you end up doing a ton of arbitrary precision int computation that is totally unnecessary. A symbolic bound is better. But especially after #126905, we can't go back to using sympy.oo, because that advertises that it's not an integer, and now your ValueRanges is typed incorrectly. So what do we do? We define a new numeric constant `int_oo`, which is like `sympy.oo` but it advertises `is_integer`. **test/test_sympy_utils.py** describes some basic properties of the number, and **torch/utils/_sympy/numbers.py** has the actual implementation. The rest of the changes of the PR are working out the implications of this change. I'll give more commentary as inline comments. Fixes pytorch/pytorch#127396 Signed-off-by: Edward Z. Yang <ezyang@meta.com> X-link: pytorch/pytorch#127693 Approved by: https://github.com/lezcano ghstack dependencies: #126905 bypass-github-export-checks pushed new commits to forward fix error Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/9cab5987bdeb66df8efbc581b3469bfe300e168c Differential Revision: D58394154 Pulled By: clee2000
facebook-github-bot
force-pushed
the
export-D58394154
branch
from
409fd7e
to
928bbd0
Compare
|
This pull request was exported from Phabricator. Differential Revision: D58394154 |
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:
In a previous life, we used sympy.oo to represent the lower/upper bounds of integer ranges. Later, we changed this to be sys.maxsize - 1 for a few reasons: (1) sometimes we do tests on a value being exactly sys.maxsize, and we wanted to avoid a data dependent guard in this case, (2) sympy.oo corresponds to floating point infinity, so you get incorrect types for value ranges with oo, and (3) you can do slightly better reasoning if you assume that input sizes fall within representable 64-bit integer range.
After working in the sys.maxsize regime for a bit, I've concluded that this was actually a bad idea. Specifically, the problem is that you end up with sys.maxsize in your upper bound, and then whenever you do any sort of size-increasing computation like size * 2, you end up with 2 * sys.maxsize, and you end up doing a ton of arbitrary precision int computation that is totally unnecessary. A symbolic bound is better.
But especially after #126905, we can't go back to using sympy.oo, because that advertises that it's not an integer, and now your ValueRanges is typed incorrectly. So what do we do? We define a new numeric constant
int_oo, which is likesympy.oobut it advertisesis_integer. test/test_sympy_utils.py describes some basic properties of the number, and torch/utils/_sympy/numbers.py has the actual implementation.The rest of the changes of the PR are working out the implications of this change. I'll give more commentary as inline comments.
Fixes pytorch/pytorch#127396
Signed-off-by: Edward Z. Yang ezyang@meta.com
X-link: pytorch/pytorch#127693
Approved by: https://github.com/lezcano
ghstack dependencies: #126905
bypass-github-export-checks pushed new commits to forward fix error
Reviewed By: clee2000
Differential Revision: D58394154
Pulled By: ezyang