issue_comments

@fjanoos there isn't any formal documentation yet but you can look at test_sparse.py for examples. That file will also tell you what works and doesn't work currently.

This is working now on the master branch!

Once we get a few more kinks worked out, it will be in the next release.

I've started another issue for discussing how xarray could integrate sparse arrays better into its API: https://github.com/pydata/xarray/issues/3213

@nvictus has been working on this at #3117

I personally use the new sparse project for my day-to-day research. I am motivated on this, but I probably won't have time today to dive deep on this.

Maybe CuPy would be more exciting.

@rgommers might be able to recommend someone

If someone who is good at numpy shows up at our sprint tomorrow, this could be a good issue try out.

It will need some experimentation, but I think things should be pretty close after NumPy 1.17 is released. Potentially it could be as easy as adjusting the rules xarray uses for casting in xarray.core.variable.as_compatible_data.

Given the recent improvements in numpy duck array typing, how close are we to being able to just wrap a pydata/sparse array in an xarray Dataset?

Would it be an option to use dask's sparse support? http://dask.pydata.org/en/latest/array-sparse.html This way xarray could let dask do the main work.

In principle this would work, though I would prefer to support it directly in xarray, too.

I know that NetCDF4 has some conventions how to store sparse data, but do we have to implement our own conversion mechanisms for each sparse type?

Yes, we would need to implement a convention for handling sparse array data.

See also: https://github.com/pydata/xarray/issues/1938

The major challenge now is the dispatching mechanism, which hopefully http://www.numpy.org/neps/nep-0018-array-function-protocol.html will solve.

Sparse Xarray DataArrays would be useful for the linear regridding operations discussed in JiaweiZhuang/xESMF#3.

@rabernat do you have an application that we could use to drive this?

Nothing comes to mind immediately. My data are unfortunately quite dense! 😜

Here is a brief attempt at a multi-dimensional sparse array: https://github.com/mrocklin/sparse

It depends on numpy and scipy.sparse and, with the exception of a bit of in-memory data movement and copies, should run at scipy speeds (though I haven't done any benchmarking).

@rabernat do you have an application that we could use to drive this?

Although I don't know much about SciDB, it seems to be another possible application for xarray.register_data_type.

👍 to the scipy.sparse array suggestion

[While we are discussing supporting other array types, we should keep gpu arrays on the radar]

Yes, I would say this is in scope, as long as we can keep most of the data-type specific logic out of xarray's core (which seems doable).

Currently, we define most of our operations on duck arrays in https://github.com/pydata/xarray/blob/master/xarray/core/duck_array_ops.py

There are a few other hacks throughout the codebase, which can find by searching for "dask_array_type": https://github.com/pydata/xarray/search?p=1&q=dask_array_type&type=&utf8=%E2%9C%93

It's pretty crude, but basically this would need to be extended to implement many of these methods on for sparse arrays, too. Ideally we would define xarray's adapter logic into more cleanly separated submodules, perhaps using multiple dispatch. Even better, we would make this public API, so you can write something like xarray.register_data_type(MySparseArray) to register a type as valid for xarray's .data attribute.

It looks like __array_ufunc__ will actually finally land in NumPy 1.13, which might make this easier.

See also https://github.com/pydata/xarray/pull/1118