I’ve found this strange behavior which I think is unexpected.
Running the following code, the last 2 printed outputs are different though I would expect the 2 operations to be equivalent:
What .contiguous() does is makes the tensor continuous in the memory disk. What is happening here is that torch.tanh is taking in the input x[:, 2, ...] and starts with the first element. Now in the disk where this is written the next elements are not what would expect in x[:, 2, ...] rather those of x[...]. So it takes in those inputs instead. This is resolved by doing .contiguous() which places them in the order you expect.
Ok, this seems to explain the behavior.
However, why don’t torch.tanh use strides to access the right values? This still seems to me an quite unexpected behaviour and it implies I need to call .contiguous() every time I use torch.tanh. I need to apply a few different non-linearities to different subsets of the channels in a CNN: calling .contiguous() on each sub-set of the channels will end up doing a complete copy of the input tensor at every forward pass, which seems a waste of resources.
Is there a way to avoid copying the whole input tensor? Do yo plan to support tensor’s strides?
I am sorry but I am not a pytorch dev so can’t really help with support thing. I usually use .contiguous() whenever the data points are sliced or permuted and hence not consecutive. torch.tanh won’t cause a problem as long as the data points are consecutive.
One possible solution is to may be permute the axes such that the values which would have the same non-linearity are consecutive. So in your case it would be something like
I saw the fixed code. It seems related to uncontiguous storage.
I am a bit confused why it related to UnaryOps.
What’s the main difference between UnaryOps and NonUnaryOps?