Undefined behavior for overflowing `.full()`

[pmeier]

Currently the specification stipulates nothing about what should happen in case full (or full_like) get passed a fill_value that overflows the dtype. For example numpy emits a RuntimeWarning and uses inf as a substitute

>>> np.full((), np.finfo(np.float64).max * 2)
<input>:1: RuntimeWarning: overflow encountered in double_scalars
array(inf)

while PyTorch bails out:

>>> torch.full((), torch.finfo(torch.float32).max * 2)
RuntimeError: value cannot be converted to type float without overflow: 6.80565e+38

I hit this discrepancy while running the API test suite against PyTorch. It uses the hypothesis' floats strategy, which includes values larger than PyTorch's default dtype (float32) can handle, together with full to generate numeric scalars. cc @asmeurer

Thus, we should either specify the behavior or fix the test suite to not rely on a specific behavior. I vote for the former.

[asmeurer]

Probably should be unspecified (meaning the test suite needs to be fixed).

[rgommers]

Agreed with Aaron. In general we try not to specify detailed warning and exception behavior, not for things like floating-point overflows (it's hardware and compiler-dependent often) nor for things like invalid inputs to functions. There's a couple of reasons for that: it's not practical to do, libraries can be opinionated here, or even offer APIs to change this behavior (e.g., numpy.errstate context manager)