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 |