@pytorchbot retest this please.

If all inputs are -inf, what would be the correct max_pool index to return?

I extended the existing algorithm, where the first index wins in case of a tie, to infinities:

>>> m = MaxPool2d(kernel_size=2, return_indices=True)
>>> v = 1.0
>>> t = torch.tensor([[[v, v], [v, v]]])
>>> m(t)
(tensor([[[1.]]]), tensor([[[0]]]))
>>> 
>>> v = float("-inf")
>>> t = torch.tensor([[[v, v], [v, v]]])
>>> m(t)
(tensor([[[-inf]]]), tensor([[[0]]]))

Compare with the current behavior:

>>> m = MaxPool2d(kernel_size=2, return_indices=True)
>>> v = float("-inf")
>>> t = torch.tensor([[[v, v], [v, v]]])
>>> m(t)
(tensor([[[-3.4028e+38]]]), tensor([[[-1]]]))

I was more concerned if the existing clamping to -3.4028e+38 was deliberate, but if it was, I cannot explain the index of -1.

@pytorchbot retest this please.

@ezyang I think this is ready for review. The issue is probably best summarized by the two code examples in this PR.

The open questions are whether returning -1 in the indices was ever valid and whether clamping -inf to -FLOAT_MAX was deliberate.

[The test failures look like known CI issues and GitHub outage fallout.]

@pytorchbot retest this please.

@pytorchbot rebase this please

I was more concerned if the existing clamping to -3.4028e+38 was deliberate, but if it was, I cannot explain the index of -1.

Blame would probably be the only way to find out, but my guess is that the person who wrote this kernel just tried to find "some minimum value" and picked the wrong one.

Waiting on CI.

@ezyang merged this pull request in 87d3f66.