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/pull/3238#issuecomment-542944296,https://api.github.com/repos/pydata/xarray/issues/3238,542944296,MDEyOklzc3VlQ29tbWVudDU0Mjk0NDI5Ng==,14808389,2019-10-17T00:25:28Z,2019-10-17T01:49:30Z,MEMBER,"I would think so, too. Go ahead.
Edit: seems like other PRs have the same problem, see #3409","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-542929485,https://api.github.com/repos/pydata/xarray/issues/3238,542929485,MDEyOklzc3VlQ29tbWVudDU0MjkyOTQ4NQ==,14808389,2019-10-16T23:16:36Z,2019-10-16T23:16:36Z,MEMBER,done,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-542922171,https://api.github.com/repos/pydata/xarray/issues/3238,542922171,MDEyOklzc3VlQ29tbWVudDU0MjkyMjE3MQ==,14808389,2019-10-16T22:46:40Z,2019-10-16T22:46:40Z,MEMBER,"I don't really know what to write about
> readers will be much more interested in what they can actually do with pint
because a feature list seems to be a bit too long to me.
re `installing.rst`: is adding `(experimental)` enough, or should the line with pip also appear there?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-542916210,https://api.github.com/repos/pydata/xarray/issues/3238,542916210,MDEyOklzc3VlQ29tbWVudDU0MjkxNjIxMA==,14808389,2019-10-16T22:23:59Z,2019-10-16T22:30:19Z,MEMBER,"I have been using a PR to hgrecco/pint#764 because that has been the version that had the most tests pass. Is that okay, or should I use the original PR instead?
So something like this?
> Added integration tests against `pint `_. Note that these tests currently require a `special version of pint ` (install with `pip install git+https://github.com/andrewgsavage/pint.git@refs/pull/6/head`) to run and are otherwise skipped. Also note that at the moment of writing, there are issues when pint interacts with non-numpy array libraries, e.g. dask or sparse.
Edit: this one works","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-542910978,https://api.github.com/repos/pydata/xarray/issues/3238,542910978,MDEyOklzc3VlQ29tbWVudDU0MjkxMDk3OA==,14808389,2019-10-16T22:04:46Z,2019-10-16T22:04:46Z,MEMBER,"what do you think of this for `whats-new.rst`?
> Added integration tests against `pint `_. Note that these tests currently require a special version of pint to run. Also note that at the moment of writing, there are issues when pint interacts with non-numpy array libraries, e.g. dask or sparse.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-542181588,https://api.github.com/repos/pydata/xarray/issues/3238,542181588,MDEyOklzc3VlQ29tbWVudDU0MjE4MTU4OA==,14808389,2019-10-15T12:13:40Z,2019-10-15T18:53:03Z,MEMBER,"I updated the PR so that all the DataArray methods I found in the docs have a test, the only exception is `to_unstacked_dataset` where I don't know what the result should look like: Consider
```python
>>> data = [[0, 10, 20], [30, 40, 50]]
>>> x = [0, 1]
>>> y = [0, 1, 2]
>>> arr = xr.DataArray(data=data, coords={""x"": x, ""y"": y}, dims=(""x"", ""y""))
>>> arr.stack(z=(""x"", ""y"")).to_unstacked_dataset(dim=""z"")
Dimensions: (y: 3)
Coordinates:
* y (y) int64 0 1 2
Data variables:
0 (y) int64 0 10 20
1 (y) int64 30 40 50
```
and supposing that indexes keep the units, what should the result of the above, but with units on `x`, look like?
Edit: I assumed this to be the same as datetime, which means object labels instead of strings. So now only the top-level functions and dataset are missing.
I'd like to leave these two and replacing `assert_equal_with_units` with either `xarray.testing.assert_identical` or `xarray.testing.assert_allclose` or a combination of both to new PRs, so now this should be ready for review.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-539748076,https://api.github.com/repos/pydata/xarray/issues/3238,539748076,MDEyOklzc3VlQ29tbWVudDUzOTc0ODA3Ng==,14808389,2019-10-08T23:34:49Z,2019-10-08T23:34:49Z,MEMBER,"that's fine with me. I resolved the merge conflicts (along with other stuff), so only `whats-new.rst` and sorting out what is to be done in new PRs are left to do.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-533145925,https://api.github.com/repos/pydata/xarray/issues/3238,533145925,MDEyOklzc3VlQ29tbWVudDUzMzE0NTkyNQ==,14808389,2019-09-19T14:04:12Z,2019-09-19T14:04:12Z,MEMBER,"I'm currently working on the tests for the comparison methods (`DataArray.equals`, `DataArray.identical` and `DataArray.broadcast_equals`) and I'm trying to figure out what `equals` and `identical` return. `equals` is easy: just make sure the wrapped quantities are equal. `identical` is a stricter version of `equals`, so I was wondering whether it should also return False if the values are equal, but in compatible units (like `10 cm` and `0.1 m`)? Any thoughts on this?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-532325585,https://api.github.com/repos/pydata/xarray/issues/3238,532325585,MDEyOklzc3VlQ29tbWVudDUzMjMyNTU4NQ==,14808389,2019-09-17T17:41:13Z,2019-09-17T17:41:13Z,MEMBER,"I'm not sure where to put this, so I'll post this here.
While working on the numpy methods part and using any of the pint versions implement `__array_function__` (hgrecco/pint#764 and andrewgsavage/pint#6) , I encountered the following:
```python
>>> array = np.array([1.3, 3.1, 7.5])
>>> array.searchsorted(2.4)
1
>>> (array * ureg.m).searchsorted(2.4 * ureg.m)
Traceback (most recent call last):
File """", line 1, in
File "".../pint/quantity.py"", line 1548, in searchsorted
raise DimensionalityError('dimensionless', self._units)
pint.errors.DimensionalityError: Cannot convert from 'dimensionless' to 'meter'
>>> (array * ureg.m).searchsorted(2.4)
pint.errors.DimensionalityError: Cannot convert from 'dimensionless' to 'meter'
>>> (array * ureg.m).searchsorted(2.4 * ureg.s)
pint.errors.DimensionalityError: Cannot convert from 'dimensionless' to 'meter'
```
I believe that is because in `BaseQuantity.searchsorted`, `self.__class__` is used to check the type, which may be either `QuantitySequence` or `QuantityScalar`. If `self` is a sequence and a scalar is passed to the method, this fails. To fix this, replacing `self.__class__` with `BaseQuantity` seems to work.
```python
>>> np.searchsorted(array * ureg.m, 2.4 * ureg.m)
>>> np.searchsorted(array * ureg.m, 2.4)
>>> np.searchsorted(array * ureg.m, 2.4 * ureg.s)
pint.errors.DimensionalityError: Cannot convert from 'second' ([time]) to 'meter' ([length])
```
I don't know what to do here (using the code from andrewgsavage/pint#6 I tried moving `searchsorted` into the same category as `isclose` -- this seems to work partially, but passing non-quantities is still allowed), but the result should be indices and incompatible units (or no unit at all) should raise an error.
Both the method and the function work fine with current master.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-531606435,https://api.github.com/repos/pydata/xarray/issues/3238,531606435,MDEyOklzc3VlQ29tbWVudDUzMTYwNjQzNQ==,14808389,2019-09-15T22:53:38Z,2019-09-15T22:53:38Z,MEMBER,"me hitting that issue is probably a bug in how `xr.Variable` handles `np.full_like` (the unit gets stripped), so no worries.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-531606126,https://api.github.com/repos/pydata/xarray/issues/3238,531606126,MDEyOklzc3VlQ29tbWVudDUzMTYwNjEyNg==,14808389,2019-09-15T22:48:30Z,2019-09-15T22:48:30Z,MEMBER,"I'm not sure whether that belongs into hgrecco/pint#882, so I'll ask this here: In the case of `full_like` with `other` being a `ndarray` and `fill_value` having a unit, numpy complains about `np.copyto` not being implemented for this type of operation:
```python
>>> np.full_like(np.arange(10), fill_value=1 * ureg.m)
Traceback (most recent call last):
File """", line 1, in
File ""<__array_function__ internals>"", line 6, in full_like
File "".../lib/python3.7/site-packages/numpy/core/numeric.py"", line 401, in full_like
multiarray.copyto(res, fill_value, casting='unsafe')
File ""<__array_function__ internals>"", line 6, in copyto
TypeError: no implementation found for 'numpy.copyto' on types that implement __array_function__: [, .QuantityScalar'>]","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-531604369,https://api.github.com/repos/pydata/xarray/issues/3238,531604369,MDEyOklzc3VlQ29tbWVudDUzMTYwNDM2OQ==,14808389,2019-09-15T22:21:56Z,2019-09-15T22:21:56Z,MEMBER,"yeah, well, I can create that index outside of pytest with
```python
pd.Index(list(np.arange(10) * ureg.m))
```
so the performance is that of an index on a python list. How that happens is beyond me, though.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-531603304,https://api.github.com/repos/pydata/xarray/issues/3238,531603304,MDEyOklzc3VlQ29tbWVudDUzMTYwMzMwNA==,14808389,2019-09-15T22:03:51Z,2019-09-15T22:03:51Z,MEMBER,"About the indexing: this might have been accidental (or a bug in pandas) and is probably a bad idea, but do you think it might be worth to somehow actively trigger this behavior in `pd.Index` for pint arrays (and possibly others) until the index refactoring from https://github.com/pydata/xarray/issues/1603#issuecomment-511126208 is done?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-531602330,https://api.github.com/repos/pydata/xarray/issues/3238,531602330,MDEyOklzc3VlQ29tbWVudDUzMTYwMjMzMA==,14808389,2019-09-15T21:48:40Z,2019-09-15T21:48:40Z,MEMBER,"I like your approach because it avoids all those issues, but stripping the units might be a surprise. Then again, what does a function named `*_like` promise? From the docs, it seems that only shape and dtype are guaranteed, so the question is whether or not the unit is part of the data or part of the type?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-531599184,https://api.github.com/repos/pydata/xarray/issues/3238,531599184,MDEyOklzc3VlQ29tbWVudDUzMTU5OTE4NA==,14808389,2019-09-15T21:03:51Z,2019-09-15T21:03:51Z,MEMBER,"I tried adding tests for `zeros_like`, `ones_like` and `full_like`, but I'm not sure what the expected result should look like, at least for the last one. I would assume `zeros_like` and `ones_like` return a quantity with the same unit as `other`, but what is the unit for `full_like`? The unit of `other`, or the unit of `fill_value`? Also, what happens if either of them has no unit, or both have units that are incompatible with each other?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-527684331,https://api.github.com/repos/pydata/xarray/issues/3238,527684331,MDEyOklzc3VlQ29tbWVudDUyNzY4NDMzMQ==,14808389,2019-09-03T23:57:11Z,2019-09-04T15:35:58Z,MEMBER,"After digging a little bit more, I think the reason why `filterwarnings()` made me think the indexing tests pass is that when a `UnitStrippedWarning` is raised (mostly after accessing `__array_struct__`), the filter replaces it with a `DimensionalityError`, complaining that it can't convert to `dimensionless`. This confuses me: when directly accessing an attribute starting with `__array_`, `pytest` correctly points out the raised `UnitStrippedWarning`.
Also, it seems that because `DimensionalityError` inherits from `ValueError`, the type of the parameter `index` of `convert_label_indexer` is changed from `Int64Index` to `Index` (which has `dtype=""object""` ), which does not cast to `ndarray`, thus keeping the unit information and causing `sel()` to correctly raise a `KeyError`. I can reproduce both behaviors using
```python
import numpy as np
import pytest
import xarray as xr
pint = pytest.importorskip(""pint"")
ureg = pint.UnitRegistry()
@pytest.mark.xfail
def test_indexing_fail():
array = np.linspace(1, 2, 20) * ureg.m
x = np.arange(len(array)) * ureg.s
data_array = xr.DataArray(data=array, coords={""x"": x}, dims=[""x""])
with pytest.raises(KeyError):
data_array.sel(x=np.array([13, 5, 9]) * ureg.m)
@pytest.mark.filterwarnings(""error:::pint[.*]"")
def test_indexing_pass():
array = np.linspace(1, 2, 20) * ureg.m
x = np.arange(len(array)) * ureg.s
data_array = xr.DataArray(data=array, coords={""x"": x}, dims=[""x""])
with pytest.raises(KeyError):
data_array.sel(x=np.array([13, 5, 9]) * ureg.m)
```
Note: the only difference between the two is the decorator.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-527244993,https://api.github.com/repos/pydata/xarray/issues/3238,527244993,MDEyOklzc3VlQ29tbWVudDUyNzI0NDk5Mw==,14808389,2019-09-02T21:24:08Z,2019-09-02T21:24:08Z,MEMBER,"It seems the reason for both the `np.median` weirdness and the indexing unexpectedly passing is the module level `filterwarnings` mark. I'm not sure why that happens, but for now I'll remove the module level mark. Also, that means that now all aggregation functions fail for data arrays, so I'll definitely have to add method tests.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-527236743,https://api.github.com/repos/pydata/xarray/issues/3238,527236743,MDEyOklzc3VlQ29tbWVudDUyNzIzNjc0Mw==,14808389,2019-09-02T20:17:36Z,2019-09-02T21:05:13Z,MEMBER,"**`np.prod`**: seems fair, and I don't especially need that function as I have been copying its use from `test_sparse.py` (though I realize now that there only the method is used). However, using `array.prod()` works on quantities, so I would expect `np.prod` to delegate to it. Same with `any()` and `all()`.
`np.median`: this also happens in my environment, so you can rule out the environment. Calling it on quantities instead of data arrays works, so the issue is within xarray. Interestingly, outside of `pytest`:
```python
>>> xr.DataArray(data=np.arange(10).astype(int) * ureg.m).median()
>>> xr.DataArray(data=np.arange(10).astype(int) * ureg.m).median()
array(4.5)
```
which seems to be a manifestation of #3241 (which is the reason I now always try different dtypes). I guess that one is not really fixed?
Also, would it be better to have a test to check the methods in addition to the numpy functions?
**Indexing**: when I wrote ""indexing works"" I meant that my tests for `sel()`, `isel()` and `loc` mostly pass (except from the ""calling `int` / `float` on scalar results"" issue). So when calling `sel()` and `loc` with either no units, dimensionless or incompatible units (but existing magnitudes), a `KeyError` is raised. In the case of both compatible units and existing magnitudes the results are also correct, but scalars trigger the error above.
Edit: I have been checking the indexing outside of `pytest` and there the units are not respected. I have no idea why, but I suspect it is at least related to the problem with `np.median`. Anyway, what is tested is:
```python
>>> array = np.linspace(5, 10, 20).astype(dtype) * ureg.m
>>> x = np.arange(len(array)) * ureg.s
>>> data_array = xr.DataArray(data=array, coords={""x"": x}, dims=[""x""])
>>> with pytest.raises(KeyError):
... data_array.sel(x=[10, 5, 13])
>>> with pytest.raises(KeyError):
... data_array.sel(x=[10, 5, 13] * ureg.dimensionless)
>>> with pytest.raises(KeyError):
... data_array.sel(x=[10, 5, 13] * ureg.m)
>>> # repr of DataArray fails with DimensionalityError
>>> data_array.sel(x=[10, 5, 13] * ureg.s).data
```
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-526955510,https://api.github.com/repos/pydata/xarray/issues/3238,526955510,MDEyOklzc3VlQ29tbWVudDUyNjk1NTUxMA==,14808389,2019-09-01T21:47:42Z,2019-09-01T21:47:42Z,MEMBER,"@jthielen: I tried my tests (those that are currently written) with your PR to hgrecco/pint#764. From the ones I have been using, `np.prod`, `np.all` and `np.any` (and also `__matmul__`, but you seem to be working on that) are missing. The question is, how many of these should be supported?
Also, there might be better ways to compare quantities, but if not: would it be possible to implement `np.allclose`? I have been using a workaround, but it seems pretty fragile to me.
You may be aware of this, but `np.minimum` and `np.maximum` and probably others similar to these are working strangely, even with plain pint: if both arguments are quantities, equal units are required, but the result is not a quantity. It correctly fails if the second argument is not a quantity, but works silently if only the second argument is a quantity (still, the result is a plain array).
As I'm not too content with it: could someone have a look at the way they are written? If there are any serious problems, it might be easier to correct them now and I can keep them in mind for new tests.
Lastly, a status report: Assuming there are no bugs in my tests and using andrewgsavage/pint#6, there are some issues with `np.argmax`/`np.argmin`, `np.median`, `np.sum` (and probably `np.prod`, but that is currently hidden). Indexing (`sel`, `isel` and `loc`) seems to work except if a single value (e.g. `1 * ureg.m`) / index is passed.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-524100935,https://api.github.com/repos/pydata/xarray/issues/3238,524100935,MDEyOklzc3VlQ29tbWVudDUyNDEwMDkzNQ==,14808389,2019-08-22T22:24:57Z,2019-08-22T22:24:57Z,MEMBER,"ah, okay, that makes sense. I will leave the `filterwarning` since I believe the warning should not be raised, but mark that test as `xfail` until a released pint version implements `__array_function__`.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016
https://github.com/pydata/xarray/pull/3238#issuecomment-524092704,https://api.github.com/repos/pydata/xarray/issues/3238,524092704,MDEyOklzc3VlQ29tbWVudDUyNDA5MjcwNA==,14808389,2019-08-22T21:54:19Z,2019-08-22T21:54:19Z,MEMBER,"@jthielen: thanks, I will look at these when I have the time.
Could you take a look at the failing test for the `DataArray`-constructor? It fails because `pint` emits a `UnitStrippedWarning` on calling `hasattr(data, ""__array_function__"")`, which I believe should not happen (correct me if I'm wrong, though).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,484015016