issue_comments: 287768014
This data as json
| html_url | issue_url | id | node_id | user | created_at | updated_at | author_association | body | reactions | performed_via_github_app | issue |
|---|---|---|---|---|---|---|---|---|---|---|---|
| https://github.com/pydata/xarray/issues/1288#issuecomment-287768014 | https://api.github.com/repos/pydata/xarray/issues/1288 | 287768014 | MDEyOklzc3VlQ29tbWVudDI4Nzc2ODAxNA== | 1386642 | 2017-03-20T14:03:10Z | 2017-03-20T14:03:10Z | CONTRIBUTOR | I usually agree that using too many (or any) switches within functions is not ideal. However, I think this is more important for low level or internal routines. For user facing interfaces, I think it is okay. After all, many numpy and scipy functions have convenient switches that control the return values. By the way, the cumtrapz implementation I pasted above matches the scipy version when initial=0, which I also think would be a more sane default for integration. As far as implementation is concerned. Is there any performance downside to using xarrays shift operators versus delving deeper into dask with map_blocks, etc? I looked into using dasks cumreduction function, but am not sure it is possible to implement the trapezoid method in that way without changing dask. On Mon, Mar 20, 2017 at 8:48 AM Fabien Maussion notifications@github.com wrote:
|
{
"total_count": 0,
"+1": 0,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
210704949 |