[Feature suggestion] Allow performing a view instead of a reshape

[samsja]

[Feature suggestion] Allow performing a view instead of a reshape

[arogozhnikov]

Ok, cool.

Anyway, wdyt of allowing custom backend?

too much hassle to pass backend each time. Don't see this as a common use-case, so this won't be a part of package

There are a number of places to achieve this behavior should you really need it:

• If you don't like existing backend - you can monkey-patch it.
• you can just copy-paste function in my_backend_einops and replace backend resolution with backend you like: https://github.com/arogozhnikov/einops/blob/master/einops/einops.py#L515

I end up implementing something similar to your implementation.

Great, I think this is the most reasonable approach.

closing this as you have a working solution

[arogozhnikov]

Hi @samsja ,

you make wrong assumptions about how torch works and subsequently how einops works.

• when it is possible to return a view, einops returns a view

from einops import rearrange
import torch
x = torch.zeros([2, 3, 4, 5])
y = rearrange(x, 'b h w c -> b c h w')

x.data_ptr() == y.data_ptr()  # outputs True

• einops allocates space for result only if that's unavoidable, because result can't be represented as a view to the input

y = rearrange(x, 'b h w c -> b (c h) w')
x.data_ptr() == y.data_ptr() # outputs False

should there be a need for rearrange_view, here is the optimal implementation:

def rearrange_view(x, pattern):
    result = rearrange(x, pattern)
    assert x.data_ptr() == result.data_ptr(), "result can't be a view to the input"
    return result

But from practitioner's perspective it is not helpful - if output can't be a view to the input, you still want to compute it.

[samsja]

Thanks for your response.

when it is possible to return a view, einops returns a view
einops allocates space for result only if that's unavoidable, because result can't be represented as a view to the input

Yes I am completely aware of this two points. I totally understand that rearrange will not copy memory if it don't have to (this is as well pytorch reshape behavior). Yet there is still a difference of utility between view and reshape. View will throw an error if it cannot do without copying memory while reshape will silently create a new tensor.

But from practitioner's perspective it is not helpful - if output can't be a view to the input, you still want to compute it.

This is arguable. In my case I specifically want this granularity and be totally sure that I am not copying anything.

I end up implementing something similar to your implementation. I guess that is fine for my use case, tho not totally optimal since you still create a new tensor, whereas view will fail before creating it. If I were working with really big tensor I could end with OOM even if I catch the assert error. Whereas torch.view no copy would have be done if I catch the view error.

Anyway, wdyt of allowing custom backend ? I can totally understand that such rearrange_view is not in einops philosophy, tho it would be nice to our own thing with the backend !

Thanks in advance