issue_comments

Sorry for the noise, I do live thinking...

However, if I do (2) there is a different behavior for (d1 * d2).sum() and d1 @ d2 in one case:

python with xr.set_options(arithmetic_join="exact"): xr.dot(d2, d3) # -> array(8) (d2 * d3).sum() # -> ValueError

So? python join = OPTIONS["arithmetic_join"] if join not in ["exact", "inner"]: join = "inner"

On second thought, even with implemented skipna the result will not differ between join="inner", join="left" join="right", and join="outer"; i.e.:

python with xr.set_options(arithmetic_join="outer"): print((d1 * d2).sum()) # -> 38 So I guess (2) is fine.

I started with a PR using join = OPTIONS["arithmetic_join"] but then I realized that dot does not support skipna. Thus join="left" join="right", and join="outer" returns NaN for nonequal coords, which I think defeats the purpose. I can

1) Use OPTIONS["arithmetic_join"] anyway 2) Only support join="inner" (i.e. hard-code it in the call to apply_ufunc) 3) try to implement skipna for dot (in a separate PR) 4) Other?

(3) is certainly the largest change but may be as easy as da.fillna(0.). Thoughts?

``` python import numpy as np import xarray as xr

d1 = xr.DataArray([2, 3, 5, np.NaN]) d2 = xr.DataArray([2, 3, 5, 7])

xr.dot(d1, d2) # -> NaN

xr.dot(d1.fillna(0.), d2) # -> 38 (d1 * d2).sum() # -> 38

```

I use this at: https://github.com/pydata/xarray/blob/3cc00c121931b5dc0247b4ea5809c4051a4dacdd/xarray/core/weighted.py#L142-L149

You could dig through the original PRs to be sure, but I think we mostly picked join='exact' out of an abundance of caution. In principle I think it would be reasonable to change it, there is a pretty good case that (d1 * d2).sum() and d1 @ d2 should be consistent.

I have no strong opinion, but if most of the arithmetic in xarray uses join='inner', then it would be nicer to do so here too.