cleanup prototype transforms functional test

[pmeier]

The goal of this PR is to facilitate best practices for our tests. In a normal scenario, these changes would be considered nitpicks. In the light of #5520 and new contributors usually (and rightfully) copy-paste code from similar tests, I think it would be beneficial to have proper usages early on.

There are two patterns I found:

1. The constructor of the new features accepts a device kwarg. Thus, something like features.Image(...).to(device) is an anti-pattern and should be replaced by features.Image(..., device=device).
2. torch.testing.assert_close is able to handle nested sequence comparison. For example, in the bounding box reference tests, we want to test the output tensor of a kernel against a two level list of values computed with another library. Instead of writing custom comparison logic for this scenario, we can simply do torch.tensor(tensor.tolist(), list_of_lists).

cc @vfdev-5

[facebook-github-bot]

💊 CI failures summary and remediations

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

---

✅ None of the CI failures appear to be your fault 💚

---

• 3/3 broken upstream at merge base 151e162 since Mar 21

---

🚧 3 ongoing upstream failures:

These were probably caused by upstream breakages that are not fixed yet.

• binary_linux_conda_py3.10_cu115 since Mar 21 (fbc8ea4)
  • 🔁 rerun
• binary_linux_conda_py3.8_cu115 since Mar 21 (fbc8ea4)
  • 🔁 rerun
• binary_linux_conda_py3.7_cu115 since Mar 21 (fbc8ea4)
  • 🔁 rerun

---

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

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

Click here to manually regenerate this comment.

[vfdev-5]

@pmeier torch.testing is in beta and may change without warning in future PyTorch releases, how problematic this could be to maintain ?

[pmeier]

As of pytorch/pytorch#73348 roughly a month ago, torch.testing is considered stable.

[NicolasHug]

Thanks @pmeier , I agree it's worth encouraging good test practices and it's best done by example. Just a random question but LGTM

[NicolasHug]

assert_close refuses to compare a list to a tensor?
IIRC numpy testing utils allow to compare array-likes with array-likes right?

[pmeier]

Yes and yes. numpy testing functions coerce everything into an np.ndarray first and than compare. We consciously opted against that for mainly two reasons:

1. If you have tests parametrized over operators like PyTorch core does, it is impossible to see if the returned type is correct. For example

   >>> expected = 1.0
   >>> np.testing.assert_allclose(np.array(expected), expected)
   >>> torch.testing.assert_close(torch.tensor(expected), expected)
   TypeError: No comparison pair was able to handle inputs of type <class 'torch.Tensor'> and <class 'float'>.

2. It allows us to compare sequences of tensors with different shapes elementwise

   >>> shapes = [(2, 3), (2, 4)]
   >>> np.testing.assert_allclose(*([np.ones(shape) for shape in shapes],) * 2)
   ValueError: could not broadcast input array from shape (2,3) into shape (2,)
   >>> torch.testing.assert_close(*([torch.ones(shape) for shape in shapes],) * 2)

   This aligns nicely with the ability of torch.testing.assert_close to compare mappings elementwise, which is not possible with the numpy functions.