Fix `fmod` type promotion #48278

ejguan · 2020-11-19T22:17:49Z

Stack from ghstack:

Fix remainder type promotion #48668 Fix remainder type promotion
Fix fmod type promotion #48278 Fix fmod type promotion

Remove various lines from tests due to no type promotion introduced from #47323

BC-breaking Note:

In order to make fmod operator have type promotion, we have to introduce BC breaking.

1.7.1:

In the case where the second argument is a python number, the result is casted to the dtype of the first argument.

>>> torch.fmod(x, 1.2)
tensor([0, 0, 0, 0, 0], dtype=torch.int32)

Prior PR:

Check the BC-breaking note of #47323

This PR:

In the case where the second argument is a python number, the dtype of result is determined by type promotion of both inputs.

>>> torch.fmod(x, 1.2)
tensor([1.0000, 0.8000, 0.6000, 0.4000, 0.2000])

BC-breaking tests:

Nightly
This PR
This PR doesn't introduce any new failure or timeout model.

Differential Revision: D25869137

[ghstack-poisoned]

ghstack-source-id: 692b680ff7106c5e5489ff05eb62870b9e07ca41 Pull Request resolved: #48278

dr-ci · 2020-11-19T23:58:21Z

💊 CI failures summary and remediations

As of commit 2ee21e3 (more details on the Dr. CI page):

4/4 failures possibly* introduced in this PR
- 2/4 non-CircleCI failure(s)

2 failures not recognized by patterns:

Job	Step	Action
^{pytorch_windows_vs2019_py36_cuda10.1_test2}	^Test	🔁 rerun
^{pytorch_ios_12_0_0_x86_64_build}	^{Run Fastlane}	🔁 rerun

ci.pytorch.org: 1 failed

Failed: pr/caffe2-pytorch-linux-bionic-rocm3.10-py3.6-test

This comment was automatically generated by Dr. CI (expand for details).

Follow this link to opt-out of these comments for your Pull Requests.

Please report bugs/suggestions to the (internal) Dr. CI Users group.

This comment has been revised 134 times.

Will fix part of #47779 Potentially fix #48130 Remove tests due to no type promotion from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

ghstack-source-id: 29d4470dabd99e79220b59005307d6438430bd79 Pull Request resolved: #48278

Will fix part of #47779 Potentially fix #48130 Remove tests due to no type promotion from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

ghstack-source-id: 86937df88bfcd84fc678a77897f3003b2e84a908 Pull Request resolved: #48278

Will fix part of #47779 Potentially fix #48130 Remove tests due to no type promotion from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

ghstack-source-id: 86937df88bfcd84fc678a77897f3003b2e84a908 Pull Request resolved: #48278

ejguan · 2020-12-01T15:47:00Z

Hey @mruberry

I am working on the type promotion for fmod (remainder will be in another PR)
All of tests are passes except one for ONNX about conflict between new type promotion and ONNX here:

pytorch/test/onnx/test_pytorch_onnx_onnxruntime.py

Lines 3840 to 3847 in c81f2d9

    
           @skipIfUnsupportedMinOpsetVersion(10) 
        
           def test_fmod_scalar(self): 
        
               class FModModel(torch.nn.Module): 
        
                   def forward(self, input): 
        
                       return torch.fmod(input, 2.55) 
        
               x = torch.randint(10, (2, 3)) 
        
               self.run_test(FModModel(), x)

The error is:

It doesn't seem ONNX have type promotion for integer fmod to floating-point scalar. (It will be same issue for remainder as well.)

Is there anyway to work around it?
I am thinking about changing the ONNX test from integral input to floating-point input.

cc: @houseroad

Will fix part of #47779 Potentially fix #48130 Remove various lines from tests due to no type promotion introduced from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

mruberry · 2020-12-02T08:48:53Z

I am working on the type promotion for fmod (remainder will be in another PR)

Cool!

All of tests are passes except one for ONNX about conflict between new type promotion and ONNX here:

That bites.

Is there anyway to work around it?
I am thinking about changing the ONNX test from integral input to floating-point input.

When I faced a similar issue the ONNX team implemented a "best effort" type promotion for the operator, see #43787. That was very generous of them.

I'd suggest giving them a chance to comment on what they'd like to see happen. Possible ideas could be:

temporarily disabling the int test and filing an issue for follow-up
consulting with them to identify an easy solution (like a calling a function in the ONNX exporter that implements the appropriate type promotion)

cc @bzinodev @spandantiwari @lara-hdr @BowenBao @neginraoof

ejguan · 2020-12-02T15:37:49Z

When I faced a similar issue the ONNX team implemented a "best effort" type promotion for the operator, see #43787. That was very generous of them.

I'd suggest giving them a chance to comment on what they'd like to see happen. Possible ideas could be:

temporarily disabling the int test and filing an issue for follow-up

consulting with them to identify an easy solution (like a calling a function in the ONNX exporter that implements the appropriate type promotion)

Thanks for the advice!

Will fix part of #47779 Remove various lines from tests due to no type promotion introduced from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

test/onnx/test_pytorch_onnx_onnxruntime.py

Will fix part of #47779 Remove various lines from tests due to no type promotion introduced from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

ejguan · 2020-12-23T22:01:40Z

Bool Tensor is not supported
>>> a = b = torch.tensor(True)
>>> torch.fmod(a, b)
RuntimeError: "fmod_cpu" not implemented for 'Bool'
>>> torch.fmod(a, 1)
RuntimeError: "fmod_scalar_cpu" not implemented for 'Bool'

This is part of the BC breaking note, but this isn't actually a BC breaking change is it?

Talked to Mike today, will follow the instruction of BC-breaking doc. I need to also update the doc that currently says the divisor can only be Tensor (same shape as dividend) or float.

gchanan · 2020-12-23T22:19:04Z

I am not sure if I should set the result dtype to int8 as NumPy or keep it as bool, as both dtypes make sense to me. #48278 (comment)

interesting question. Maybe a good question for @rgommers for what numpy intends to support. As far as I can tell, this is defined by the types the ufunc defines, e.g. np.fmod.types is different than np.multiply.types -- if all your "wrap ufunc" code actually uses ufuncs, you could write the function in terms of the types instead of memorizing the combinations.

gchanan · 2020-12-23T22:25:14Z

Ah ya, ? represents np.bool_ (see https://numpy.org/devdocs/reference/arrays.scalars.html#numpy.bool_), and np.multiply.types has ??->? but np.fmod.types doesn't. You can also see this by passing dtype=np.bool_ to the operator.

ejguan · 2020-12-23T22:43:57Z

I am not sure if I should set the result dtype to int8 as NumPy or keep it as bool, as both dtypes make sense to me. #48278 (comment)

interesting question. Maybe a good question for @rgommers for what numpy intends to support. As far as I can tell, this is defined by the types the ufunc defines, e.g. np.fmod.types is different than np.multiply.types -- if all your "wrap ufunc" code actually uses ufuncs, you could write the function in terms of the types instead of memorizing the combinations.

I understand types gives me the rules of NumPy operators. But it won't tell me the difference of type promotion rules. What I can make the wrapper_fn better is:

# Special cases
# tensor & number
# boolean tensor & boolean tensor
...
# General cases
if hasattr(x, 'dtype') and hasattr(y, 'dtype'):
    if np.promote_types(x.dtype, y.dtype) != torch.promote_types(n2t[x.dtype], n2t[y.dtype]):
        return t2n[torch.promote_types(numpy2torch[x.dtype], numpy2torch[y.dtype])]

This is going to work without explicitly running the combination of case 2) in the comment.

rgommers · 2020-12-24T10:47:29Z

I am not sure if I should set the result dtype to int8 as NumPy or keep it as bool, as both dtypes make sense to me. #48278 (comment)

interesting question. Maybe a good question for @rgommers for what numpy intends to support. As far as I can tell, this is defined by the types the ufunc defines, e.g. np.fmod.types is different than np.multiply.types -- if all your "wrap ufunc" code actually uses ufuncs, you could write the function in terms of the types instead of memorizing the combinations.

What NumPy does right now seems right to me, and I can't find any discussion about fmod of boolean arrays. Casting to integer for numerical operations sounds reasonable in general, and for fmod in particular the result is meant to be signed so using bool output would be odd I think.

mruberry · 2020-12-28T13:52:57Z

aten/src/ATen/native/cpu/BinaryOpsKernel.cpp

-  // Issue #47779: https://github.com/pytorch/pytorch/issues/47779
-  if (isIntegralType(iter.dtype(), /*includeBool=*/ false)) {
-    AT_DISPATCH_INTEGRAL_TYPES(iter.dtype(), "fmod_cpu", [&]() {
+  if (isIntegralType(iter.common_dtype(), /*includeBool=*/ true)) {


Since bool dispatch is (slightly) controversial let's just remove it for now. It's true that NumPy promotes to int8 in this case, but for analogous cases, like True + True, NumPy will not promote.

mruberry · 2020-12-28T13:53:21Z

aten/src/ATen/native/cuda/BinaryRemainderKernel.cu

-  // Issue #47779: https://github.com/pytorch/pytorch/issues/47779
-  if (isIntegralType(iter.dtype(), /*includeBool*/ false)) {
-    AT_DISPATCH_INTEGRAL_TYPES(iter.dtype(), "fmod_cuda", [&]() {
+  if (isIntegralType(iter.common_dtype(), /*includeBool*/ true)) {


Remove bool dispatch here, too. We can revisit it in a later PR.

mruberry · 2020-12-28T14:04:37Z

torch/testing/_internal/common_methods_invocations.py

@@ -349,6 +349,80 @@ def wrapped_fn(x):

    return wrapped_fn

+def np_binary_ufunc_type_promotion_wrapper(fn):


I appreciate the attention to detail with this function, and we may bring it back later, but for this PR a simpler approach is probably to remove this function and the following two and, instead, just use torch.result_type and pre-cast all the NumPy inputs to the corresponding NumPy dtype. For example:

dtype = torch.result_type(input0, input1) np_input0 = input0.to(dtype).cpu().numpy() np_input1 = input1.to(dtype).cpu().numpy().

Or, even simpler, to just ignore the dtype in the comparison:

self.assertEqual(expected, actual, exact_dtype=False)

I think either of these solutions will work for this PR, and for the remainder PR, too. Let me know if you have questions about this; we can review it together.

I will choose the second solution because it's still required some hard code for the corner cases for arguments with tensor and python number.

mruberry

I have two remaining suggestions:

let's error on bool for now
let's simplify the type promotion discrepancy (ping me to discuss this further)

Other than that things look good.

Remove various lines from tests due to no type promotion introduced from #47323 ## BC-breaking Note: In order to make `fmod` operator have type promotion, we have to introduce BC breaking. ### 1.7.1: - For two tensor arguments, output dtype is determined by the first input (Tensor). So it won't support floating-point to int casting and raise RuntimeError. ```python >>> x = torch.arange(start=1, end=6, dtype=torch.int32) # tensor([1, 2, 3, 4]) >>> y = torch.arange(start=1.1, end=2.1, step=0.2, dtype=torch.float32) # tensor([1.1, 1.3, 1.5, 1.7, 1.9]) >>> torch.fmod(x, y) RuntimeError: result type Float can't be cast to the desired output type Int >>> z = torch.arange(start=0.2, end=1.1, step=0.2, dtype=torch.float64) # tensor([0.2, 0.4, 0.6, 0.8, 1.], dtype=torch.float64) >>> torch.fmod(y, z).dtype torch.float32 >>> torch.fmod(z, y).dtype torch.float64 ``` - For tensor and scalar arguments, the result is casted to the dtype of the first argument. ```python >>> torch.fmod(x, 1.2) tensor([0, 0, 0, 0, 0], dtype=torch.int32) ``` - Bool Tensor is **not supported** ```python >>> a = b = torch.tensor(True) >>> torch.fmod(a, b) RuntimeError: "fmod_cpu" not implemented for 'Bool' >>> torch.fmod(a, 1) RuntimeError: "fmod_scalar_cpu" not implemented for 'Bool' ``` ### [Prior PR](#47323): - For two tensor arguments, ```python >>> x = torch.arange(start=1, end=6, dtype=torch.int32) # tensor([1, 2, 3, 4]) >>> y = torch.arange(start=1.1, end=2.1, step=0.2, dtype=torch.float32) # tensor([1.1, 1.3, 1.5, 1.7, 1.9]) >>> torch.fmod(x, y) tensor([1.0000, 0.7000, 0.0000, 0.6000, 1.2000]) >>> z = torch.arange(start=0.2, end=1.1, step=0.2, dtype=torch.float64) # tensor([0.2, 0.4, 0.6, 0.8, 1.], dtype=torch.float64) >>> torch.fmod(y, z).dtype torch.float64 >>> torch.fmod(z, y).dtype torch.float64 ``` - For tensor and scalar arguments, the result is casted to the dtype of the first argument. ```python >>> torch.fmod(x, 1.2) tensor([0, 0, 0, 0, 0], dtype=torch.int32) ``` - Bool Tensor is **not supported** ```python >>> a = b = torch.tensor(True) >>> torch.fmod(a, b) RuntimeError: "fmod_cpu" not implemented for 'Bool' >>> torch.fmod(a, 1) RuntimeError: "fmod_cpu" not implemented for 'Bool' ``` ### Current: - Type is determined by both inputs. ```python >>> x = torch.arange(start=1, end=6, dtype=torch.int32) # tensor([1, 2, 3, 4]) >>> y = torch.arange(start=1.1, end=2.1, step=0.2, dtype=torch.float32) # tensor([1.1, 1.3, 1.5, 1.7, 1.9]) >>> torch.fmod(x, y) tensor([1.0000, 0.7000, 0.0000, 0.6000, 1.2000]) >>> z = torch.arange(start=0.2, end=1.1, step=0.2, dtype=torch.float64) # tensor([0.2, 0.4, 0.6, 0.8, 1.], dtype=torch.float64) >>> torch.fmod(y, z).dtype torch.float64 >>> torch.fmod(z, y).dtype torch.float64 ``` - For tensor and scalar arguments, the dtype of result is promoted. ```python >>> torch.fmod(x, 1.2) tensor([1.0000, 0.8000, 0.6000, 0.4000, 0.2000]) ``` - Bool Tensor is **supported** as inputs ```python >>> a = b = torch.tensor(True) >>> torch.fmod(a, b) tensor(False) >>> torch.fmod(a, 0.7) tensor(0.3000) ``` Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

Remove various lines from tests due to no type promotion introduced from #47323 ## BC-breaking Note: In order to make `fmod` operator have type promotion, we have to introduce BC breaking. ### 1.7.1: In the case where the second argument is a python number, the result is casted to the dtype of the first argument. ```python >>> torch.fmod(x, 1.2) tensor([0, 0, 0, 0, 0], dtype=torch.int32) ``` ### Prior PR: Check the BC-breaking note of #47323 ### This PR: In the case where the second argument is a python number, the dtype of result is determined by type promotion of both inputs. ```python >>> torch.fmod(x, 1.2) tensor([1.0000, 0.8000, 0.6000, 0.4000, 0.2000]) ``` Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

Remove various lines from tests due to no type promotion introduced from #47323 ## BC-breaking Note: In order to make `fmod` operator have type promotion, we have to introduce BC breaking. ### 1.7.1: In the case where the second argument is a python number, the result is casted to the dtype of the first argument. ```python >>> torch.fmod(x, 1.2) tensor([0, 0, 0, 0, 0], dtype=torch.int32) ``` ### Prior PR: Check the BC-breaking note of #47323 ### This PR: In the case where the second argument is a python number, the dtype of result is determined by type promotion of both inputs. ```python >>> torch.fmod(x, 1.2) tensor([1.0000, 0.8000, 0.6000, 0.4000, 0.2000]) ``` [ghstack-poisoned]

torch/_torch_docs.py

mruberry

This looks good, nice work, @ejguan. I've made a few small suggestions for the documentation and a simple change to the kernel functions that should be easy to implement. Once this is imported we should run an additional BC-breaking test on the PR, just in case. Ping me and I can talk you through our process for doing that.

mruberry · 2021-01-12T12:50:21Z

aten/src/ATen/native/cuda/BinaryRemainderKernel.cu

-  if (isIntegralType(iter.dtype(), /*includeBool*/ false)) {
-    AT_DISPATCH_INTEGRAL_TYPES(iter.dtype(), "fmod_cuda", [&]() {
+  if (isIntegralType(iter.common_dtype(), /*includeBool*/ false)) {
+    AT_DISPATCH_INTEGRAL_TYPES(iter.common_dtype(), "fmod_cuda", [&]() {
      gpu_kernel_with_scalars(iter, []GPU_LAMBDA(scalar_t a, scalar_t b) -> scalar_t {
        return a % b;
      });
    });
  } else {


Take this dispatch out of the else branch, like this:

if ... { } # dispatch

I think we still need to keep it within the else block. Otherwise, we will dispatch two times for this operation.

Oh I see what you're saying, yes that's fine. Sorry. Please ignore my suggestions to take them out, we can keep them in the branch.

mruberry · 2021-01-12T12:50:45Z

aten/src/ATen/native/cpu/BinaryOpsKernel.cpp

      cpu_kernel(iter, [=](scalar_t x, scalar_t d) -> scalar_t {
        TORCH_CHECK(d != 0, "ZeroDivisionError");
        return x % d;
      });
    });
  } else {
-    AT_DISPATCH_FLOATING_TYPES_AND(kHalf, iter.dtype(), "fmod_cpu", [&]() {
+    AT_DISPATCH_FLOATING_TYPES_AND(kHalf, iter.common_dtype(), "fmod_cpu", [&]() {


Take this dispatch out of the else branch

Remove various lines from tests due to no type promotion introduced from #47323 ## BC-breaking Note: In order to make `fmod` operator have type promotion, we have to introduce BC breaking. ### 1.7.1: In the case where the second argument is a python number, the result is casted to the dtype of the first argument. ```python >>> torch.fmod(x, 1.2) tensor([0, 0, 0, 0, 0], dtype=torch.int32) ``` ### Prior PR: Check the BC-breaking note of #47323 ### This PR: In the case where the second argument is a python number, the dtype of result is determined by type promotion of both inputs. ```python >>> torch.fmod(x, 1.2) tensor([1.0000, 0.8000, 0.6000, 0.4000, 0.2000]) ``` Differential Revision: [D25869137](https://our.internmc.facebook.com/intern/diff/D25869137) [ghstack-poisoned]

facebook-github-bot · 2021-01-13T06:09:54Z

@ejguan merged this pull request in a0f7b18.

Fix fmod type promotion

6a2c7b5

[ghstack-poisoned]

ejguan mentioned this pull request Nov 19, 2020

Migrate fmod and fmod_ from TH to ATen (CUDA) #47323

Closed

ejguan added a commit that referenced this pull request Nov 19, 2020

Fix fmod type promotion

2a87ab6

ghstack-source-id: 692b680ff7106c5e5489ff05eb62870b9e07ca41 Pull Request resolved: #48278

facebook-github-bot added the cla signed label Nov 19, 2020

ejguan changed the title ~~Fix fmod type promotion~~ [WIP] Fix fmod type promotion Nov 19, 2020

Update on "[WIP] Fix fmod type promotion"

a717ae1

Will fix part of #47779 Potentially fix #48130 Remove tests due to no type promotion from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

ejguan added a commit that referenced this pull request Nov 20, 2020

Fix fmod type promotion (Fix tests)

a88f382

ghstack-source-id: 29d4470dabd99e79220b59005307d6438430bd79 Pull Request resolved: #48278

Update on "[WIP] Fix fmod type promotion"

5033286

Will fix part of #47779 Potentially fix #48130 Remove tests due to no type promotion from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

Update on "[WIP] Fix fmod type promotion"

43531d6

Will fix part of #47779 Potentially fix #48130 Remove tests due to no type promotion from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

ejguan added a commit that referenced this pull request Nov 30, 2020

Fix fmod type promotion (Fix tests)

7a421a9

ghstack-source-id: 86937df88bfcd84fc678a77897f3003b2e84a908 Pull Request resolved: #48278

Update on "[WIP] Fix fmod type promotion"

c8a1df7

Will fix part of #47779 Potentially fix #48130 Remove tests due to no type promotion from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

ejguan added a commit that referenced this pull request Nov 30, 2020

Fix fmod type promotion (Fix tests)

2011339

ghstack-source-id: 86937df88bfcd84fc678a77897f3003b2e84a908 Pull Request resolved: #48278

Update on "[WIP] Fix fmod type promotion"

353a616

Will fix part of #47779 Potentially fix #48130 Remove various lines from tests due to no type promotion introduced from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

ejguan mentioned this pull request Dec 1, 2020

Fix remainder type promotion #48668

Closed

mruberry added the module: onnx Related to torch.onnx label Dec 2, 2020

ejguan added 2 commits December 2, 2020 15:10

Update on "[WIP] Fix fmod type promotion"

b64d2c7

Will fix part of #47779 Remove various lines from tests due to no type promotion introduced from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

Update on "[WIP] Fix fmod type promotion"

b274f94

Will fix part of #47779 Remove various lines from tests due to no type promotion introduced from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

ejguan mentioned this pull request Dec 2, 2020

PyTorch's fmod and remainder cannot be exported to ONNX with consistent semantics (Type promotion) #48739

Closed

Update on "[WIP] Fix fmod type promotion"

5f5a2d6

Will fix part of #47779 Remove various lines from tests due to no type promotion introduced from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

spandantiwari requested review from BowenBao and neginraoof December 3, 2020 18:17

ejguan changed the title ~~[WIP] Fix fmod type promotion~~ Fix fmod type promotion Dec 3, 2020

houseroad reviewed Dec 8, 2020

View reviewed changes

test/onnx/test_pytorch_onnx_onnxruntime.py Outdated Show resolved Hide resolved

ejguan added 2 commits December 9, 2020 10:58

Update on "Fix fmod type promotion"

052f33d

Will fix part of #47779 Remove various lines from tests due to no type promotion introduced from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

Update on "Fix fmod type promotion"

8a3a335

Will fix part of #47779 Remove various lines from tests due to no type promotion introduced from #47323 Differential Revision: [D25105245](https://our.internmc.facebook.com/intern/diff/D25105245) [ghstack-poisoned]

mruberry reviewed Dec 28, 2020

View reviewed changes

ejguan added 7 commits December 28, 2020 12:19

ejguan requested a review from mruberry January 11, 2021 14:34

mruberry reviewed Jan 12, 2021

View reviewed changes

torch/_torch_docs.py Outdated Show resolved Hide resolved

mruberry reviewed Jan 12, 2021

View reviewed changes

torch/_torch_docs.py Outdated Show resolved Hide resolved

mruberry reviewed Jan 12, 2021

View reviewed changes

torch/_torch_docs.py Outdated Show resolved Hide resolved

mruberry approved these changes Jan 12, 2021

View reviewed changes

mruberry reviewed Jan 12, 2021

View reviewed changes

facebook-github-bot closed this in a0f7b18 Jan 13, 2021

facebook-github-bot added the Merged label Jan 13, 2021

facebook-github-bot deleted the gh/ejguan/9/head branch January 16, 2021 15:18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix `fmod` type promotion #48278

Fix `fmod` type promotion #48278

ejguan commented Nov 19, 2020 •

edited

Loading

dr-ci bot commented Nov 19, 2020 •

edited by facebook-github-bot

Loading

ejguan commented Dec 1, 2020 •

edited

Loading

mruberry commented Dec 2, 2020

ejguan commented Dec 2, 2020

ejguan commented Dec 23, 2020 •

edited

Loading

gchanan commented Dec 23, 2020 •

edited

Loading

gchanan commented Dec 23, 2020

ejguan commented Dec 23, 2020

rgommers commented Dec 24, 2020

mruberry Dec 28, 2020

mruberry Dec 28, 2020

mruberry Dec 28, 2020 •

edited

Loading

ejguan Dec 28, 2020

mruberry left a comment

mruberry left a comment •

edited

Loading

mruberry Jan 12, 2021

ejguan Jan 12, 2021

mruberry Jan 12, 2021 •

edited

Loading

mruberry Jan 12, 2021

facebook-github-bot commented Jan 13, 2021

		@@ -349,6 +349,80 @@ def wrapped_fn(x):

		return wrapped_fn

		def np_binary_ufunc_type_promotion_wrapper(fn):

Fix fmod type promotion #48278

Fix fmod type promotion #48278

Conversation

ejguan commented Nov 19, 2020 • edited Loading

BC-breaking Note:

1.7.1:

Prior PR:

This PR:

BC-breaking tests:

dr-ci bot commented Nov 19, 2020 • edited by facebook-github-bot Loading

💊 CI failures summary and remediations

2 failures not recognized by patterns:

ci.pytorch.org: 1 failed

ejguan commented Dec 1, 2020 • edited Loading

mruberry commented Dec 2, 2020

ejguan commented Dec 2, 2020

ejguan commented Dec 23, 2020 • edited Loading

gchanan commented Dec 23, 2020 • edited Loading

gchanan commented Dec 23, 2020

ejguan commented Dec 23, 2020

rgommers commented Dec 24, 2020

mruberry Dec 28, 2020

Choose a reason for hiding this comment

mruberry Dec 28, 2020

Choose a reason for hiding this comment

mruberry Dec 28, 2020 • edited Loading

Choose a reason for hiding this comment

ejguan Dec 28, 2020

Choose a reason for hiding this comment

mruberry left a comment

Choose a reason for hiding this comment

mruberry left a comment • edited Loading

Choose a reason for hiding this comment

mruberry Jan 12, 2021

Choose a reason for hiding this comment

ejguan Jan 12, 2021

Choose a reason for hiding this comment

mruberry Jan 12, 2021 • edited Loading

Choose a reason for hiding this comment

mruberry Jan 12, 2021

Choose a reason for hiding this comment

facebook-github-bot commented Jan 13, 2021

Fix `fmod` type promotion #48278

Fix `fmod` type promotion #48278

ejguan commented Nov 19, 2020 •

edited

Loading

dr-ci bot commented Nov 19, 2020 •

edited by facebook-github-bot

Loading

ejguan commented Dec 1, 2020 •

edited

Loading

ejguan commented Dec 23, 2020 •

edited

Loading

gchanan commented Dec 23, 2020 •

edited

Loading

mruberry Dec 28, 2020 •

edited

Loading

mruberry left a comment •

edited

Loading

mruberry Jan 12, 2021 •

edited

Loading