home / github / issues

Menu
  • GraphQL API
  • Search all tables

issues: 596062033

This data as json

id node_id number title user state locked assignee milestone comments created_at updated_at closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
596062033 MDU6SXNzdWU1OTYwNjIwMzM= 3950 Consistent Handling of Type Casting Hierarchy 3460034 open 0     0 2020-04-07T18:20:49Z 2020-04-07T18:36:22Z   CONTRIBUTOR      

As brought up in #3643, there appears to be some inconsistencies in how xarray handles other numeric/duck array types with regards to a well-defined type casting hierarchy across operations. For example, in the following:

Construction/Wrapping

  • Allows
  • xarray.core.indexing.ExplicitlyIndexed
  • pandas.Index
  • Dask array
  • __array_function__ implementers
  • Automatically converts
  • Anything with a values attribute to its values
  • Datetime-like array types
  • Masked arrays
  • Anything else for which np.asarray(data) is valid
  • Doesn't reject any type when trying to wrap (for an upcast type such as a HoloViews Dataset, this may be needed?)

Binary Ops

  • Defers based on xarray's internal hierarchy (Dataset, DataArray, Variable), otherwise relies upon methods of underlying data, and then wraps result.

(would be one less category to worry about if refactored to use __array_ufunc__, see https://github.com/pydata/xarray/pull/3936#issuecomment-610516784)

__array_ufunc__

  • Allows a list of supported types https://github.com/pydata/xarray/blob/9b5140e0711247c373987b56726282140b406d7f/xarray/core/arithmetic.py#L24-L30 along with SupportsArithmetic
  • Defers to all other types

__array_function__

  • To be implemented (https://github.com/pydata/xarray/issues/3917)

One concrete example of where this has been problematic is with xarray DataArrays and Pint Quantities (#3643). xarray DataArray is above Pint Quantity in the (generally agreed upon) type casting hierarchy, and wrapping and binary ops work properly since Pint Quantities defer and xarray DataArrays handle the operation. However, ufuncs fail because they both attempt to defer to the other. Having a consistent way of handling type compatibility across all relevant areas in xarray should be able to remove these kinds of issues.

However, it would be good to keep in mind that an agreed upon way of how to do this in the broader ecosystem doesn't seem to be there yet, so this would still be treading in uncertain waters for the moment. I've been operating under these assumptions when working with Pint, but I definitely think there is a need for more authoritative guidance.

Also, if I'm mistaken in any of the things mentioned above, please do let me know!

cc @keewis, @shoyer

{
    "url": "https://api.github.com/repos/pydata/xarray/issues/3950/reactions",
    "total_count": 2,
    "+1": 2,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
    13221727 issue

Links from other tables

  • 1 row from issues_id in issues_labels
  • 0 rows from issue in issue_comments
Powered by Datasette · Queries took 0.579ms · About: xarray-datasette