With the latest build I get:

ERROR: test_crop (__main__.TestNN)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_nn.py", line 693, in test_crop
    self.assertEqual(c1(v1).sum(), v1[:, :, 3:7].sum())
  File "/Users/bodokaiser/.pyenv/versions/pytorch/lib/python3.6/site-packages/torch/nn/modules/module.py", line 207, in __call__
    for hook in self._forward_hooks.values():
  File "/Users/bodokaiser/.pyenv/versions/pytorch/lib/python3.6/site-packages/torch/nn/modules/module.py", line 238, in __getattr__
    type(self).__name__, name))
AttributeError: 'Crop1d' object has no attribute '_forward_hooks'

Is this an inheritance problem?

@apaszke @fmassa

I also thought of a version which would supports arbitrary dimensions (passes tests too).

def center_crop(x, *args):
    size = x.size()[2:]
    ndim = len(size)
    assert ndim == len(args), 'Crop dimensions do not match input dimensions'
    def crop(y, dim):
        offset = math.ceil((size[dim] - args[dim]) / 2)
        length = size[dim] - offset
        indices = torch.arange(offset, length)
        if isinstance(x, autograd.Variable):
            indices = autograd.Variable(indices)
        y = y.index_select(2 + dim, indices.long())
        if dim == 0:
            return y
        return crop(y, dim - 1)
    return crop(x, ndim - 1)

We've discussed this PR and decided that it'd be best to only add nn.Crop and F.crop. They should accept a mode argument (in this case 'center') and a size - a tuple that defines how many dims should be expected (e.g. if size == (2, 3, 4) then it should expect 5D inputs).

1. Should we default to mode='center-left'? With center-left meaning that when one dimension is odd e.g. [1, 2, 3, 4, 5] we get [2, 3] where as mode=center-right would yield [3, 4].
2. Does size accept arbitrary dimensions? If yes should we use my recusrive implementation in the former post?

I think we should support center (either defaulting to center-left or to an error when it would have to slice unevenly), but center-left and center-right sound good too. Your recursive implementation looks good, except that it doesn't work for CUDA and shouldn't use index_select (slicing should be enough and will be muuuuuuuch faster). You can use narrow

I'm closing this for now. Feel free to reopen when you update your branch.

Yeah its still on my list I hope I find time for it the next weeks. Sorry for the delay.