-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aggregation functions treat duck arrays differently depending on dtype #3241
Comments
This seams to be an issue with pint and is worked on in hgrecco/pint#764: using that PR instead of the version available in conda-forge makes all functions fail with a So I guess this can be closed? |
now that I hit this issue using the example from #3238 again, this seems to be a bug in xarray. For reference, this is the mentioned example that fails even with a pint version with >>> xr.DataArray(data=np.arange(10).astype(int) * ureg.m).median()
<xarray.DataArray ()>
<Quantity(4.5, 'meter')>
>>> xr.DataArray(data=np.arange(10).astype(float) * ureg.m).median()
<xarray.DataArray ()>
array(4.5) |
@keewis could you clarify that example? Both those examples appear to be the same code, with different results! |
that's true. I edited it, the float version should fail. The new example is actually the same as the first one, but using |
Can you try merging in the latest version of xarray master into your branch? I think this issue was fixed just recently by #3254. When I test this myself, both versions seem to do the right thing:
|
you're right, after merging the issue is gone for me, too. |
While working on #3238, I tried replacing
np.arange
withnp.linspace
to create test arrays:Judging by the build logs of #3238, this seems to be the case for all aggregation functions except from
np.median
and of course those that return booleans or indices.The text was updated successfully, but these errors were encountered: