issue_comments

Looks good. Merge?

I moved the docs around and added a note on multi-dimensional indexing.

I was thinking about only allowing it to work only if the array has exactly matching coordinates. Which would be the case in (4) a[(x > 0) & (y > 0)]. But then it would be difficult to stay consistent in the 1d case- mask or select?

My sense is that we'll probably be happier if we have entirely distinct APIs for masking (.where) and selection ([] and .loc[]).

That's a concrete and easy to understand distinction. I'm convinced.

Oh, wow -- I didn't even realize that worked in pandas! Combined with NA-skipping aggregation functions in pandas that makes expressions like a[a < 0].mean() work just like the same expression in NumPy.

So instead of adding where, perhaps we should just support boolean indexing like pandas.

The main difference is that where can cleanly support broadcasting, whereas we currently don't do broadcasting in indexing. For example, suppose a is a 2-dimensional DataArray with dimensions (x, y). Now considering the following cases: 1. a[x > 0] 2. a[y > 0] 3. a[x > 0, y > 0] 4. a[(x > 0) & (y > 0)]

Currently, (1) and (3) work by selection. If we adopt the pandas behavior, (4) would also work, but by broadcasting and masking. This seems like a potential recipe for confusion, because once you have (4), case (2) seems like a natural variation. We could implement (2), but should it mask or select?

My sense is that we'll probably be happier if we have entirely distinct APIs for masking (.where) and selection ([] and .loc[]).

Right. Consider following pandas rather than numpy here:

``` In [9]: a = pd.DataFrame(np.random.randn(3, 4))

In [10]: a Out[10]: 0 1 2 3 0 -1.188669 0.055286 -0.476962 0.144261 1 1.779646 2.332629 0.326515 -0.179862 2 -0.016739 1.221892 -0.032720 -0.779563

In [11]: a[a < 0] Out[11]: 0 1 2 3 0 -1.188669 NaN -0.476962 NaN 1 NaN NaN NaN -0.179862 2 -0.016739 NaN -0.032720 -0.779563 ```

Both R and pandas allow the user to do a[a < 0] and a[a < 0] = 0. So what I'm wondering is why not extend xray's indexing to also work on arrays that are the same shape and have the same labels as the original array?

The problem is that a[a < 0] in NumPy flattens arrays with more than one dimension. We can't do this in xray without doing something like pointwise indexing to flatten out the labels, too.

Agreed- if a[a < 0] = 0 works then a[a < 0] should work also.

Both R and pandas allow the user to do a[a < 0] and a[a < 0] = 0. So what I'm wondering is why not extend xray's indexing to also work on arrays that are the same shape and have the same labels as the original array?

Right now, you can do that by chaining two operations: a.where(a > 0).fillna(0). It would definitely be better to support it in one (a.where(a > 0, 0)).

I suppose we could also support a[a < 0] = 0, but it seems a little strange given that we don't support a[a < 0].

Here's something related that one can do in Numpy- replace all negative entries with 0.

``` In [15]: a = np.arange(-5, 5).reshape(2, 5)

In [16]: a Out[16]: array([[-5, -4, -3, -2, -1], [ 0, 1, 2, 3, 4]])

In [17]: a[a < 0] = 0

In [18]: a Out[18]: array([[0, 0, 0, 0, 0], [0, 1, 2, 3, 4]]) ```

Would it be possible to modify __getitem__ for this common use case?

@clarkfitzg Yes, that's mostly right. The main differences: 1. The order of the arguments here is different, to match the pandas methods (which has more of a SQL flavor to it). 2. I'm not exposing the third argument, because xray objects don't yet implement broadcasting operations with more than 2 arguments at once. This is something that needs refactoring -- the logic in _binary_op should be generalized to any number of arguments.

Checking if I understand- this exists in line 79 of ops.py

where = _dask_or_eager_func('where')

so this PR is to expose it in the users API?

Plot makes for a compelling example.