8000 Keep zero check be compatible with different sympy versions by guangyey · Pull Request #130729 · pytorch/pytorch · GitHub
[go: up one dir, main page]

Skip to content

Keep zero check be compatible with different sympy versions #130729

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

Closed
wants to merge 3 commits into from

Conversation

guangyey
Copy link
Collaborator
@guangyey guangyey commented Jul 15, 2024

Stack from ghstack (oldest at bottom):

Motivation

I found a difference between sympy 1.12 and 1.13.

# for 1.12
>>> import sympy
>>> a = sympy.Number(0.0)
>>> a == 0
True
# for 1.13
>>> import sympy
>>> a = sympy.Number(0.0)
>>> a == 0
False

The different behavior will impact the result of safe_mul, resulting in an incorrect results when a = sympy.Number(0.0), b = inf and the result is nan if sympy version is 1.13. (the expected result is 0)

def safe_mul(a, b):
    # Make unknown() * wrap(0.0) == wrap(0.0)
    if a == 0.0:
        return a
    elif b == 0.0:
        return b
    else:
        return a * b

In different sympy versions, sympy.Number(0) always has the same behavior that equals to 0.0.

>>> import sympy
>>> a = sympy.Number(0)
>>> a == 0.0
True # for different sympy versions

So, use 0.0 when checking zero in safe_mul to keep compatible with different sympy versions.

cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10

Copy link
pytorch-bot bot commented Jul 15, 2024

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/130729

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit 0a837f7 with merge base 39eeaac (image):
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

@pytorch-bot pytorch-bot bot added the module: cpu CPU specific problem (e.g., perf, algorithm) label Jul 15, 2024
@guangyey guangyey changed the title Keep zero check be compatible with sympy>=1.13 Keep zero check be compatible with different sympy versions Jul 15, 2024
@guangyey guangyey requested review from ezyang and lezcano July 15, 2024 12:02
@guangyey guangyey added ciflow/inductor intel This tag is for PR from Intel labels Jul 15, 2024
@guangyey guangyey requested review from EikanWang and gujinghui July 15, 2024 12:03
Copy link
Collaborator
@lezcano lezcano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uf, this is surely going to bite us in other places...

@guangyey guangyey added the ciflow/trunk Trigger trunk jobs on your pull request label Jul 15, 2024
@Skylion007
Copy link
Collaborator

Uf, this is surely going to bite us in other places...

I guess we should enforce the latest sympy version only?

@guangyey
Copy link
Collaborator Author

Uf, this is surely going to bite us in other places...

I guess we should enforce the latest sympy version only?

#130689 intends to enforce to upgrade sympy version to 1.13 or later.

@guangyey
Copy link
Collaborator Author

@pytorchbot rebase -b main

@pytorchmergebot
Copy link
Collaborator

@pytorchbot started a rebase job onto refs/remotes/origin/main. Check the current status here

@pytorchmergebot
Copy link
Collaborator

Successfully rebased gh/guangyey/52/orig onto refs/remotes/origin/main, please pull locally before adding more changes (for example, via ghstack checkout https://github.com/pytorch/pytorch/pull/130729)

guangyey added 2 commits July 15, 2024 19:45
[ghstack-poisoned]
@guangyey
Copy link
Collaborator Author

@pytorchbot rebase -b main

@pytorchmergebot
Copy link
Collaborator

@pytorchbot started a rebase job onto refs/remotes/origin/main. Check the current status here

[ghstack-poisoned]
@pytorchmergebot
Copy link
Collaborator

Successfully rebased gh/guangyey/52/orig onto refs/remotes/origin/main, please pull locally before adding more changes (for example, via ghstack checkout https://github.com/pytorch/pytorch/pull/130729)

pytorchmergebot pushed a commit that referenced this pull request Jul 16, 2024
ghstack-source-id: a2614d6
Pull Request resolved: #130729
@guangyey
Copy link
Collaborator Author

@pytorchbot merge

@pytorchmergebot
Copy link
Collaborator

Merge failed

Reason: This PR needs a release notes: label
If your changes are user facing and intended to be a part of release notes, please use a label starting with release notes:.

If not, please add the topic: not user facing label.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "topic: not user facing"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

Details for Dev Infra team Raised by workflow job

@guangyey
Copy link
Collaborator Author

@pytorchbot merge

@pytorchmergebot
Copy link
Collaborator

Merge started

Your change will be merged once all checks pass (ETA 0-4 Hours).

Learn more about merging in the wiki.

Questions? Feedback? Please reach out to the PyTorch DevX Team

Advanced Debugging
Check the merge workflow status
here

# Make unknown() * wrap(0) == wrap(0)
if a == 0:
# Make unknown() * wrap(0.0) == wrap(0.0)
if a == 0.0:
8000 Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a is 0 (integer) does this still match it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

>>> import sympy
>>> a = sympy.Number(0)
>>> a == 0.0
True # for different sympy versions

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that is_zero is a better choice.

>>> import sympy
>>> a = sympy.Number(0)
>>> a.is_zero
True
>>> b = sympy.Number(0.0)
>>> b.is_zero
True

mlazos pushed a commit that referenced this pull request Jul 18, 2024
# Motivation
I found a difference between sympy 1.12 and 1.13.
```python
# for 1.12
>>> import sympy
>>> a = sympy.Number(0.0)
>>> a == 0
True
```
```python
# for 1.13
>>> import sympy
>>> a = sympy.Number(0.0)
>>> a == 0
False
```
The different behavior will impact the result of [safe_mul](https://github.com/pytorch/pytorch/blob/6beec34b1c6803d5f6648c3cd7c262d6432374c8/torch/utils/_sympy/value_ranges.py#L521-L528), resulting in an incorrect results when `a = sympy.Number(0.0)`, `b = inf` and the result is `nan` if sympy version is 1.13. (the expected result is **0**)
```python
def safe_mul(a, b):
    # Make unknown() * wrap(0.0) == wrap(0.0)
    if a == 0.0:
        return a
    elif b == 0.0:
        return b
    else:
        return a * b
```

In different sympy versions, `sympy.Number(0)` always has the same behavior that equals to 0.0.
```python
>>> import sympy
>>> a = sympy.Number(0)
>>> a == 0.0
True # for different sympy versions
```
So, use 0.0 when checking zero in safe_mul to keep compatible with different sympy versions.

Pull Request resolved: #130729
Approved by: https://github.com/lezcano, https://github.com/EikanWang
XuehaiPan pushed a commit to XuehaiPan/pytorch that referenced this pull request Jul 22, 2024
…130729)

# Motivation
I found a difference between sympy 1.12 and 1.13.
```python
# for 1.12
>>> import sympy
>>> a = sympy.Number(0.0)
>>> a == 0
True
```
```python
# for 1.13
>>> import sympy
>
9E88
;>> a = sympy.Number(0.0)
>>> a == 0
False
```
The different behavior will impact the result of [safe_mul](https://github.com/pytorch/pytorch/blob/6beec34b1c6803d5f6648c3cd7c262d6432374c8/torch/utils/_sympy/value_ranges.py#L521-L528), resulting in an incorrect results when `a = sympy.Number(0.0)`, `b = inf` and the result is `nan` if sympy version is 1.13. (the expected result is **0**)
```python
def safe_mul(a, b):
    # Make unknown() * wrap(0.0) == wrap(0.0)
    if a == 0.0:
        return a
    elif b == 0.0:
        return b
    else:
        return a * b
```

In different sympy versions, `sympy.Number(0)` always has the same behavior that equals to 0.0.
```python
>>> import sympy
>>> a = sympy.Number(0)
>>> a == 0.0
True # for different sympy versions
```
So, use 0.0 when checking zero in safe_mul to keep compatible with different sympy versions.

Pull Request resolved: pytorch#130729
Approved by: https://github.com/lezcano, https://github.com/EikanWang
xuhancn pushed a commit to xuhancn/pytorch that referenced this pull request Jul 25, 2024
…130729)

# Motivation
I found a difference between sympy 1.12 and 1.13.
```python
# for 1.12
>>> import sympy
>>> a = sympy.Number(0.0)
>>> a == 0
True
```
```python
# for 1.13
>>> import sympy
>>> a = sympy.Number(0.0)
>>> a == 0
False
```
The different behavior will impact the result of [safe_mul](https://github.com/pytorch/pytorch/blob/6beec34b1c6803d5f6648c3cd7c262d6432374c8/torch/utils/_sympy/value_ranges.py#L521-L528), resulting in an incorrect results when `a = sympy.Number(0.0)`, `b = inf` and the result is `nan` if sympy version is 1.13. (the expected result is **0**)
```python
def safe_mul(a, b):
    # Make unknown() * wrap(0.0) == wrap(0.0)
    if a == 0.0:
        return a
    elif b == 0.0:
        return b
    else:
        return a * b
```

In different sympy versions, `sympy.Number(0)` always has the same behavior that equals to 0.0.
```python
>>> import sympy
>>> a = sympy.Number(0)
>>> a == 0.0
True # for different sympy versions
```
So, use 0.0 when checking zero in safe_mul to keep compatible with different sympy versions.

Pull Request resolved: pytorch#130729
Approved by: https://github.com/lezcano, https://github.com/EikanWang
@github-actions github-actions bot deleted the gh/guangyey/52/head branch August 17, 2024 01:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ciflow/inductor ciflow/trunk Trigger trunk jobs on your pull request intel This tag is for PR from Intel Merged module: cpu CPU specific problem (e.g., perf, algorithm) open source topic: not user facing topic category
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

7 participants
0