[opinfo] nn.functional.unfold

[kshitij12345]

Reference: pytorch/functorch#78

[facebook-github-bot]

🔗 Helpful links

• 🧪 See artifacts and rendered test results at hud.pytorch.org/pr/62705
• 📄 Preview docs built from this PR

💊 CI failures summary and remediations

As of commit ea61279 (more details on the Dr. CI page):

---

💚 💚 Looks good so far! There are no failures yet. 💚 💚

---

This comment was automatically generated by Dr. CI (expand for details).

Follow this link to opt-out of these comments for your Pull Requests.

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

[krshrimali]

This looks great, thanks @kshitij12345! I added a comment on how we can a few more cases for completeness.

It's interesting though, that we have an OpInfo for unfold already (wasn't aware of this) but I'm not sure we need to keep it (or if it's any different) since it doesn't cover dilation, padding, stride args:

pytorch/torch/testing/_internal/common_methods_invocations.py

Lines 7687 to 7694 in 773a8ee

	OpInfo('unfold',
	op=lambda x, *args: x.unfold(*args),
	dtypes=all_types_and_complex_and(torch.bool, torch.float16, torch.bfloat16),
	supports_out=False,
	supports_forward_ad=True,
	check_batched_gradgrad=False,
	skips=(
	# torch.unfold does not exist so we get a RuntimeError.

Thanks!

[kshitij12345]

torch.unfold is actually different from nn.functional.unfold (function implementation as well as API). That is why a new entry.

pytorch/aten/src/ATen/native/native_functions.yaml

Line 7356 in 773a8ee

- func: unfold(Tensor(a) self, int dimension, int size, int step) -> Tensor(a)

pytorch/torch/nn/functional.py

Line 4481 in 773a8ee

return torch._C._nn.im2col(input, _pair(kernel_size), _pair(dilation), _pair(padding), _pair(stride))

[krshrimali]

LGTM, thanks @kshitij12345!

[zou3519]

One really minor comment about the inputs shape. But I'm also happy to merge this as-is and add the shape in a follow-up, please let me know how you'd like to proceed

[facebook-github-bot]

@zou3519 has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[zou3519]

I wonder if we should partition OpInfos across multiple files to avoid merge conflicts. Right now I can only really merge one of these PRs a day (two sometimes if I'm lucky) because I need to rebase internally, ship it, and then wait for the change to reach viable/strict.

[kshitij12345]

This is being pursued in #59871

(Though targeting a particular kind of OpInfo like nn.functional will still lead to conflicts)

[facebook-github-bot]

@zou3519 merged this pull request in 64c54f9.