-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] support for xarray
DataArray
& mtypes
#3255
Conversation
TODOs
|
for conditional execution (based on presence of package in the env), you can use: if _check_soft_dependencies("xarray", severity="none"):
import xarray
etc |
let me know if you think you are stuck - I can look at this is more detail, we can do pair programming, or I can give it a try. |
Thank you, I let you know if I am stuck |
I have two questions:
|
Depends what you need it for. If needed in this PR, we can leave it in its location and refactor.
Yes, |
* Use store dict for xarray DataArray conversion * Fix linting errors in newly added code.
Ok, it is not needed for the xarray topic. |
7eb4ad4
to
81c4aec
Compare
81c4aec
to
4654248
Compare
Update:I am currently working on probably transforming the index from pandas to xarray and vice versa. I assume that this is caused by the transpose which I apply to have the same shape after the conversion chain: pd.DataFrame -> xr.DataArray -> pd.DataFrame. A solution for this will probably also solve also the problem with the tests in python 3.7 (it seems that in python 3.7 the index is a BaseIndex after the conversion, while for 3.8 and 3.9 it is a PeriodIndex) |
…ons which swap the dimensions.. * Append deep_equals for xarray testing.
Ouch... how odd. I suppose this is one of those non-obvious problems that occur... |
👏 nice! Looks like it passes now! |
return concat_fun | ||
|
||
|
||
def _extend_conversions(mtype, anchor_mtype, convert_dict): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If datatypes is refactored, then this method should be placed somewhere else. Currently similar methods are implemented in panels and tables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, indeed - too much copy-paste!
Though I would go with incurring technical debt due to priorities...
Re refactor directions:
@chrisholder started sth, but abandoned it.
#1460
Haven´t had the time to salvage it.
This would be another option:
dylan-profiler/visions#194
Yeah 🥳 Should we add the support for other mtypes and the dataset in this PR or should I create additional PRs for the other? |
I would go with the "minimal modular change" principle and separate PR, also finalizing this one first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice, thanks!
if this were not a draft, I would have only one blocking change, that's the coupling introduced in deep_equals
, can we avoid it?
* Enable xarray with only one dimension (Explicit transformation to pandas DataFrame instead of using to_pandas) * Add identity transformation from xr.DataArray to xr.DataArray
Update
|
xarray
DataArray
& mtypes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works!
Do you want me to merge this, or wait for panel?
I would merge it and add the panel with a second PR if I need this. Currently, I can test and go on with the sktime-pyWATTS integration without implementing Panels. Perhaps Issue #2655 should stay open in that case. |
@fkiraly Do we have to adapt utils.validation.series? In that file, something like VALID_DATA_TYPES is defined. Do I have to add xr.DataArray? |
I think that's used only in legacy code, so I would recommend to not touch it (who knows what will break). The "critical touch point" is |
Reference Issues/PRs
resolves #2655
What does this implement/fix? Explain your changes.
Does your contribution introduce a new dependency? If yes, which one?
What should a reviewer concentrate their feedback on?
Any other comments?
PR checklist
For all contributions
For new estimators