issue_comments

Table actions

2 rows where issue = 207962322 and user = 1217238 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

  • shoyer · 2 ✖

issue 1

  • Attrs are lost in mathematical computation · 2 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
280574680 https://github.com/pydata/xarray/issues/1271#issuecomment-280574680 https://api.github.com/repos/pydata/xarray/issues/1271 MDEyOklzc3VlQ29tbWVudDI4MDU3NDY4MA== shoyer 1217238 2017-02-17T07:25:20Z 2017-02-17T07:28:29Z MEMBER

Coordinate reference systems (crs) are an example of attribute which is always valid after selection, arithmetic, or even reduction since they apply to the coordinates of the DataArray.

I wonder if it might make sense to represent crs as a (scalar) coordinate, which would already be propagated in all unambiguous cases by xarray ops.

The main reason why this is annoying is that ds.crs would return a 0-dimensional DataArray, so you would need to write ds.crs.item() to access it directly (e.g., if you want to call a method on it). Though you could actually already use the accessor interface to fix this (see this gist for details).

Could the setting not be module-wide, but be set on DataArray instances themselves? That setting could then be inherited when new ones are created from arithmetic operations.

I would strong prefer to avoid making the xarray data model more complex by adding another type of metadata (e.g., in addition to dims, coords, attrs and name on DataArray). Whitelisting specific attrs as ones that should be preserved in application code via set_options (or encouraging users to subclass DataArray in a "safe" way) is preferable in that regard.

Either way, this issue is related to the fuller "hook" system for customized attribute handling that I imagined over in #988.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Attrs are lost in mathematical computation 207962322
280208293 https://github.com/pydata/xarray/issues/1271#issuecomment-280208293 https://api.github.com/repos/pydata/xarray/issues/1271 MDEyOklzc3VlQ29tbWVudDI4MDIwODI5Mw== shoyer 1217238 2017-02-16T02:11:22Z 2017-02-16T02:12:25Z MEMBER

Historically, we dropped attributes in arithmetic because attributes are often used for units and we didn't want to do computation that results in the wrong units. Blinding propagating metadata can lead to it ending up in the wrong place.

Also, if you are combining multiple DataArray objects with different attrs, there are a number of options for combining them, and it wasn't obvious which is the right strategy.

But in practice, this is something that a lot of people want (better to have stale metadata than no metadata at all), so maybe I made the wrong choice here. At the very least, I would be comfortable with an option to set keep_attrs=True for every operation and/or to specify a merge strategy for combining attrs in arithmetic. (I guess I've changed my opinion from when rejected this proposal from @jhamman several years ago.)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Attrs are lost in mathematical computation 207962322

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);