Repository navigation
diff to allow Python scalar or 0d array append and prepend? #930
Description
The specification of diff requires append and prepend to be arrays with the same shape as the first argument except along axis.
array-api-strict currently does not:
import array_api_strict as xp
xp.diff(xp.ones((2, 3)), append=xp.asarray(10), axis=0)
# Array([[0., 0., 0.],
# [9., 9., 9.]], dtype=array_api_strict.float64)
xp.diff(xp.ones((2, 3)), append=xp.asarray(10), axis=1)
# Array([[0., 0., 9.],
# [0., 0., 9.]], dtype=array_api_strict.float64)Like NumPy, CuPy, and JAX, it expands the value as necessary (and follows the same promotion rules as other functions. I see that following the usual promotion rules was already tabled, so I won't bring that up again right now.)
This suggest that the operation can be well-defined, and I think it can be useful (e.g. prepend 0 and append shape[axis]). It would be even more useful to accept Python scalars, following the example of clip (which also requires array min/max to have the same type as x, but allows Python scalars). This would avoid requiring the user to do something like:
append = xp.full(x.shape[:axis] + (1,) + x.shape[axis:], append, dtype=xp.result_type(x, prepend, append))
Activity
[-]`diff` to allow Python scalar or 0d array`append` and `prepend`?[/-][+]`diff` to allow Python scalar or 0d array `append` and `prepend`?[/+]kgryte commentedon Apr 18, 2025
As noted in #791, scalar kwargs support is not supported in PyTorch, which was a primary motivation for restricting portable behavior to
prependandappendbeing arrays.kgryte commentedon Apr 18, 2025
Also ref: #784
mdhaber commentedon Apr 18, 2025
Thanks for those references; good to see it was considered.
I understand that when a library doesn't support a feature that the rest do, the standard needs to strike a balance between importance of the feature and difficulty of adding support. Features like
uint16-uint64support, asizeattribute, negative step sizes for slices, etc. are very challenging for for PyTorch to add and impossible forarray-api-compatto compensate for within its current scope, but the standard includes them because they are very important. (Thank goodness!)This is a lot less important than those features, but it is also much easier to add. data-apis/array-api-compat#271 and data-apis/array-api-compat#274 have several other examples of PyTorch lacking support for scalars (and these are just the ones I've run across), but the standard decided to include them. I'd suggest that this could be similar.