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/3349#issuecomment-565600745,https://api.github.com/repos/pydata/xarray/issues/3349,565600745,MDEyOklzc3VlQ29tbWVudDU2NTYwMDc0NQ==,6628425,2019-12-13T20:39:21Z,2019-12-13T20:39:21Z,MEMBER,"Excellent, looking forward to seeing it in a PR!","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-565462443,https://api.github.com/repos/pydata/xarray/issues/3349,565462443,MDEyOklzc3VlQ29tbWVudDU2NTQ2MjQ0Mw==,6628425,2019-12-13T14:33:53Z,2019-12-13T14:33:53Z,MEMBER,"If I understand correctly, `pd.to_numeric` (and its inverse) works because it always uses 1970-01-01T00:00:00 as the reference date.  Could we do something similar when working with cftime dates?

Within xarray we typically convert dates to numeric values (e.g. when doing interpolation) using `xarray.core.duck_array_ops.datetime_to_numeric`, which takes an optional `offset` argument to control the reference date.  Would it work to always make sure to pass 1970-01-01T00:00:00 with the appropriate calendar type as the offset when constructing the ordinal x-coordinate for `polyfit`/`polyval`?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-561241142,https://api.github.com/repos/pydata/xarray/issues/3349,561241142,MDEyOklzc3VlQ29tbWVudDU2MTI0MTE0Mg==,2448579,2019-12-03T16:17:00Z,2019-12-03T16:17:00Z,MEMBER,xyzpy has a polyfit too : https://xyzpy.readthedocs.io/en/latest/manipulate.html,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-537622127,https://api.github.com/repos/pydata/xarray/issues/3349,537622127,MDEyOklzc3VlQ29tbWVudDUzNzYyMjEyNw==,1217238,2019-10-02T18:30:25Z,2019-10-02T18:30:25Z,MEMBER,"It seems like these are getting reinvented often enough that it's worth
pulling some of these into xarray proper.

On Wed, Oct 2, 2019 at 9:04 AM Ryan Abernathey <notifications@github.com>
wrote:

> I'm getting deja-vu here... Xscale has a huge and impressive sounding API.
> But no code coverage and no commits since January. Like many of these
> projects, it seems to have bit off more than its maintainers could chew.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/pydata/xarray/issues/3349?email_source=notifications&email_token=AAJJFVV5XANAGSPKHSF6KZLQMTA7HA5CNFSM4I3HCUUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFJCDI#issuecomment-537563405>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAJJFVREMUT5RKJJESG5NVLQMTA7HANCNFSM4I3HCUUA>
> .
>
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-537563405,https://api.github.com/repos/pydata/xarray/issues/3349,537563405,MDEyOklzc3VlQ29tbWVudDUzNzU2MzQwNQ==,1197350,2019-10-02T16:04:02Z,2019-10-02T16:06:20Z,MEMBER,"I'm getting deja-vu here... Xscale has a huge and impressive sounding API. But no code coverage and no commits since January. Like many of these projects, it seems to have bit off more than its maintainers could chew.

_Edit: I'd love for such a package to really achieve community uptake and become sustainable. I just don't quite know the roadmap for getting there._","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-537552488,https://api.github.com/repos/pydata/xarray/issues/3349,537552488,MDEyOklzc3VlQ29tbWVudDUzNzU1MjQ4OA==,2448579,2019-10-02T15:40:04Z,2019-10-02T15:40:04Z,MEMBER,https://xscale.readthedocs.io/en/latest/generated/xscale.signal.fitting.polyfit.html#xscale.signal.fitting.polyfit,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-536690748,https://api.github.com/repos/pydata/xarray/issues/3349,536690748,MDEyOklzc3VlQ29tbWVudDUzNjY5MDc0OA==,1217238,2019-09-30T18:29:10Z,2019-09-30T18:29:10Z,MEMBER,"From a user perspective, I think people prefer to find stuff in one place.

From a maintainer perspective, as long as it's somewhat domain agnostic (e.g., ""physical sciences"" rather than ""oceanography"") and written to a reasonable level of code quality, I think it's fine to toss it into xarray. ""Already exists in NumPy/SciPy"" is probably a reasonable proxy for the former.

So I say: yes, let's toss in polyfit, along with fast fourier transforms.

If we're concerned about clutter, we can put stuff in a dedicated namespace, e.g., `xarray.wrappers`.","{""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-536670564,https://api.github.com/repos/pydata/xarray/issues/3349,536670564,MDEyOklzc3VlQ29tbWVudDUzNjY3MDU2NA==,1197350,2019-09-30T17:42:57Z,2019-09-30T17:42:57Z,MEMBER,"Now that xarray itself has interpolate, gradient, and integrate, it seems like the only thing left in xr-scipy is fourier transforms, which is also what we provide in [xrft](https://github.com/xgcm/xrft)! 😆 ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-536663815,https://api.github.com/repos/pydata/xarray/issues/3349,536663815,MDEyOklzc3VlQ29tbWVudDUzNjY2MzgxNQ==,2448579,2019-09-30T17:25:38Z,2019-09-30T17:25:38Z,MEMBER,The quickest way to close this is probably to extend @fujiisoup's xr-scipy(https://github.com/fujiisoup/xr-scipy) to wrap `scipy.linalg.lstsq` and `dask.array.linalg.lstsq`. It is likely that all the necessary helper functions already exist.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-536654572,https://api.github.com/repos/pydata/xarray/issues/3349,536654572,MDEyOklzc3VlQ29tbWVudDUzNjY1NDU3Mg==,1197350,2019-09-30T17:01:57Z,2019-09-30T17:01:57Z,MEMBER,"The question of a standalone library has come up many times (see discussion in #1850). Everyone agrees it's a nice idea, but no one seems to have the bandwidth to take on ownership and maintenance of such a project.

Perhaps we need to put this issue on pause and figure out a general strategy here. The current Xarray API is far from a complete feature set, so more development is needed. But we should decide what belongs in xarray and what belongs elsewhere. #1850 is probably the best place to continue that conversation.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-536078107,https://api.github.com/repos/pydata/xarray/issues/3349,536078107,MDEyOklzc3VlQ29tbWVudDUzNjA3ODEwNw==,35968931,2019-09-27T20:02:02Z,2019-09-27T20:02:02Z,MEMBER,"I am in favour of adding this (and other common functionality), but I would comment that perhaps we should move forward with discussion about where to put extra functionality generally (the scipy to xarray's numpy if you will)? If only because otherwise the API could get to an unwieldy size? 

I can't remember where the relevant issue was, but for example this might go under an `xarray.utils` module?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363
https://github.com/pydata/xarray/issues/3349#issuecomment-535967743,https://api.github.com/repos/pydata/xarray/issues/3349,535967743,MDEyOklzc3VlQ29tbWVudDUzNTk2Nzc0Mw==,2448579,2019-09-27T14:39:02Z,2019-09-27T15:07:33Z,MEMBER,"dask has `lstsq` https://docs.dask.org/en/latest/array-api.html#dask.array.linalg.lstsq . Would that avoid the dimension-must-have-one-chunk issue?

EDIT: I am in favour of adding this. It's a common use case like `differentiate` and `integrate`","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,499477363