[numpy] torch.exp: promote integer inputs to float

[kshitij12345]

Reference: #42515

[facebook-github-bot]

💊 CI failures summary and remediations

As of commit 9134f8c (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.

This comment has been revised 4 times.

[kshitij12345]

Reason for skipping BFloat16

>>> torch.tensor(8.8750, device='cuda:0', dtype=torch.bfloat16)
tensor(8.8750, device='cuda:0', dtype=torch.bfloat16)
>>> t = torch.tensor(8.8750, device='cuda:0', dtype=torch.bfloat16)
>>> torch.exp(t)
tensor(7136., device='cuda:0', dtype=torch.bfloat16)
>>> torch.exp(t.to(torch.float32))
tensor(7150.9463, device='cuda:0')

[codecov]

Codecov Report

Merging #50093 (9134f8c) into master (6e6231f) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master   #50093      +/-   ##
==========================================
- Coverage   80.67%   80.66%   -0.02%     
==========================================
  Files        1899     1899              
  Lines      206066   206066              
==========================================
- Hits       166241   166219      -22     
- Misses      39825    39847      +22     

[mruberry]

Awesome! Thanks @kshitij12345!

I don't want to interrupt your flow because the progress on these PRs has been great, but would you take a look at creating an OpInfo for torch.tile?

We need to be very careful about its performance. See #49962. A recent PR reduced the size of the tensors generated by its method_test entries to reduce the time those tests took. We should probably respect those sizes.

While creating the OpInfo for tile, would you also review the following:

• was torch.tile implemented correctly? that is, is it really like np.tile? Note that torch.tile is not a unary ufunc, so while we can create an OpInfo for jit and autograd testing it will still need its own forward tests to validate its behavior. These tests exist, but are they complete?
• can torch.repeat be implemented as a call to torch.tile? I understand that torch.tile is actually implemented as a call to repeat currently, but from a UX standpoint, could we alias torch.repeat to torch.tile? It's true that torch.tile can accept more inputs than torch.repeat, but will every valid input to torch.repeat produce the same output when given to torch.tile?

I'm especially interested in this because of #50013. I'm not suggesting that we proceed with the deprecation in that issue, but I'd like more data about torch.tile and torch.repeat to make an informed decision.

Bonus points if the PR also creates an OpInfo for torch.repeat and/or merges their "forward" tests together.

[facebook-github-bot]

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

[kshitij12345]

Awesome! Thanks @kshitij12345!

I don't want to interrupt your flow because the progress on these PRs has been great, but would you take a look at creating an OpInfo for torch.tile?

We need to be very careful about its performance. See #49962. A recent PR reduced the size of the tensors generated its method_test entries to reduce the time those tests took. We should probably respect those sizes.

While creating the OpInfo for tile, would you also review the following:

• was torch.tile implemented correctly? that is, is it really like np.tile? Note that torch.tile is not a unary ufunc, so while we can create an OpInfo for jit and autograd testing it will still need its own forward tests to validate its behavior. These tests exist, but are they complete?
• can torch.repeat be implemented as a call to torch.tile? I understand that torch.tile is actually implemented as a call to repeat currently, but from a UX standpoint, could we alias torch.repeat to torch.tile? It's true that torch.tile can accept more inputs than torch.repeat, but will every valid input to torch.repeat produce the same output when given to torch.tile?

I'm especially interested in this because of #50013. I'm not suggesting that we proceed with the deprecation in that issue, but I'd like more data about torch.tile and torch.repeat to make an informed decision.

Bonus points if the PR also creates an OpInfo for torch.repeat and/or merges their "forward" tests together.

Sure. Thanks for the pointers!

[facebook-github-bot]

@mruberry merged this pull request in 9f832c8.