BUG: `full_like` and `full` accept array `fill_value`

[lucascolley]

In [1]: import array_api_strict as xp

In [2]: xp.full_like(xp.asarray(0), xp.asarray(1))
Out[2]: Array(1, dtype=array_api_strict.int64)

Spec:

fill_value (Union[bool, int, float, complex]) – fill value.

[asmeurer]

This seems like it should be fixed in the standard. Getting a fill value from an array seems like it wouldn't be uncommon.

[kgryte]

Torch only accepts a scalar in full and full_like. To update the standard, I'd want to see upstream support added first.

[lucascolley]

Dask also throws a FutureWarning since its implementation uses np.copyto, which it says may stop working with dask arrays in the future.

[crusaderky]

xp.full has the same issue.

[lucascolley]

@ev-br is this issue blocked by upstream? I know it sounds like we want to add this behaviour to the standard, but until it is added, can't we remove it from array-api-strict?

[ev-br]

Yes, exactly. If it's going to be standardized soon, do we want the churn of removing it now and readding it back?
Re adding it to the standard: I think it makes total sense. Without it, one needs something like full(zeroD_array.item()), which causes a device synchronization for a GPU backend.

[lucascolley]

If it's going to be standardized soon

Do you know if there is any progress on the PyTorch side?

[ev-br]

Sadly, no, I don't.

[lucascolley]

No movement on PyTorch yet: pytorch/pytorch#154077