html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/4858#issuecomment-773647435,https://api.github.com/repos/pydata/xarray/issues/4858,773647435,MDEyOklzc3VlQ29tbWVudDc3MzY0NzQzNQ==,12862013,2021-02-04T22:33:45Z,2021-02-04T22:34:30Z,CONTRIBUTOR,"> My suggestion is:
> 1. replace the example with arr.pad(x=1, constant_values=1.23456789) and mention that the float is cast to int (or would you leave the example away?)
> 2. open a new issue to discuss the issue of assigning float to int
I agree, I think that would be a good solutions for now, I think replacing the example is fine. Maybe we could even open a new issue, to discuss how xarray functions handle `np.nan`.
Is `dask.array.pad` gonna handle casting the same way? It would be strange if the cast to float happens, depending on the underlying array type. But that discussion should probably happen in the newly opened issue ;-)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,800118528
https://github.com/pydata/xarray/issues/4858#issuecomment-773240852,https://api.github.com/repos/pydata/xarray/issues/4858,773240852,MDEyOklzc3VlQ29tbWVudDc3MzI0MDg1Mg==,12862013,2021-02-04T11:33:32Z,2021-02-04T11:34:36Z,CONTRIBUTOR,"Hi, we had a similar discussion in de #3596, xarray makes a distinction between `np.nan` and `xarray.dtypes.NaN`. The current behaviour is consistent with that of other xarray functions such as `shift`. Though, I am personally not a big fan of this distinction.
Check e.g. this comment: https://github.com/pydata/xarray/pull/3596#discussion_r388612638
The example I posted in this comment:
```
>>> da = xr.DataArray(np.arange(9).reshape(3,3), dims=(""x"", ""y""))
>>> da.shift(x=1, fill_value=np.nan)
array([[-9223372036854775808, -9223372036854775808, -9223372036854775808],
[ 0, 1, 2],
[ 3, 4, 5]])
Dimensions without coordinates: x, y
>>> da.rolling(x=3).construct(""new_axis"", stride=3, fill_value=np.nan)
array([[[-9223372036854775808, -9223372036854775808, 0],
[-9223372036854775808, -9223372036854775808, 1],
[-9223372036854775808, -9223372036854775808, 2]]])
Dimensions without coordinates: x, y, new_axis
```
Hmm, so numpy changed its behaviour? Then this example, should probably also fail in numpy 1.20.
On a side note: I am not a big fan of the example in the doctest, it displays an edge case, which is not unique to `pad`.
I think the nicest solution would be to make the usage `xarray.dtypes.NaN` and `np.nan` equivalent. But this would require changes in all xarray functions that take some kind of `fill_value`. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,800118528