Skip to content

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

@pytorch-bot
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:
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
>>> 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.

8 participants