Issue 1:
🐛 Bug

Per documentation of MaxPool, input is "implicitly zero-padded on both sides for padding number of points." The implementation differs by implicitly padding with identity elements, rather than zero.

To Reproduce

Steps to reproduce the behavior:

Create a tensor of signed type, filled with negative values.

Invoke a MaxPool with positive padding.

Compare against ground truth, either computed by hand or created by explicit zero-padding.

Minimal code sample / unit test:

# Maxpool of non-positive values, such that padding is included in the computation of each result element.
import torch
r = torch.nn.functional.max_pool2d(-torch.rand(2,2,64), kernel_size=[3,3], padding=1)
assert torch.equal(r, torch.zeros_like(r))

Expected behavior

According to documentation, the values near the edge will be computed using the implicit zero-padding. The maximum of a negative number and zero is zero, so such values ought to be zero. In the provided example, the assert should not fire.

When the code sample above is run, however, the assert fires.

Environment

Information from collect_env.py:

PyTorch version: 1.5.1

Is debug build: No

CUDA used to build PyTorch: 10.2

OS: Microsoft Windows 10 Home

GCC version: (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0

CMake version: version 3.14.1

Python version: 3.8

Is CUDA available: Yes

CUDA runtime version: Could not collect

GPU models and configuration: GPU 0: GeForce GTX 960M

Nvidia driver version: 442.50

cuDNN version: Could not collect

Versions of relevant libraries:

[pip] Could not collect

[conda] Could not collect

Additional context

N/A

cc @ezyang @gchanan @zou3519 @jlin27 @albanD @mruberry

Issue 2:
🐛 Bug

According to the documentation on nn.MaxPool1d:

If padding is non-zero, then the input is implicitly zero-padded on both sides for padding number of points. dilation controls the spacing between the kernel points. It is harder to describe, but this link has a nice visualization of what dilation does.

However, the input is never padded with zeros, either explicitly or implicitly. Doing a bit of source diving I found that the maximum operation initializes with negative infinity, not zero, and only considers entries from the original, unpadded input tensor. Therefore it would be correct to say that the max-pooling operation uses implicit negative infinity padding but not zero-padding.

This appears to be either a bug in the API or documentation (of course PEBCAK is always a possibility).

To Reproduce

Steps to reproduce the behavior:

Install PyTorch

Run the following code

>>> import torch
>>> from torch.nn.functional import max_pool1d
>>> x = torch.tensor([[[-1., -2.]]])
>>> max_pool1d(x, kernel_size=2, padding=1)
tensor([[[-1., -2.]]])
>>> max_pool1d(x.cuda(), kernel_size=2, padding=1)
tensor([[[-1., -2.]]], device='cuda:0')

Expected behavior

If zero-padding was being used we would expect the output to be tensor([[[0., 0.]]]) since zero is larger than all the input tensor elements.

Environment

PyTorch version: 1.4.0

Is debug build: No

CUDA used to build PyTorch: 10.1

OS: Red Hat Enterprise Linux Workstation release 7.7 (Maipo)

GCC version: (GCC) 6.3.0

CMake version: version 3.11.4

Python version: 3.7

Is CUDA available: Yes

CUDA runtime version: 10.0.130

GPU models and configuration:

GPU 0: GeForce RTX 2080 Ti

GPU 1: GeForce RTX 2080 Ti

Nvidia driver version: 430.40

cuDNN version: 7.6.3

Versions of relevant libraries:

[pip3] numpy==1.18.1

[pip3] torch==1.4.0

[pip3] torchvision==0.5.0

[conda] Could not collect

Additional context

This issue is based on a question originally asked on StackOverflow by user trsvchn.

cc @jlin27 @mruberry @heitorschueroff