-
-
Notifications
You must be signed in to change notification settings - Fork 25.8k
Any plans to stabilize IterativeImputer? What are the current roadblocks to doing so? #16638
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
Comments
My concerns are described in #14338. Basically there is no common definition of what convergence means from what I know. In particular, the common case of MissForest where the regressor is a random forest regressor has no useful convergence criterion on scikit-learn. |
Thanks. This would be helpful to add to the documentation in the "Note" box on the IterativeImputer page. Maybe that'd make it easier for people to get involved in fixing the convergence issue. |
PR welcome, @skeller88 |
Ok cool. I'll try and get to that if I can.
…On Wed, Apr 1, 2020 at 6:27 PM Joel Nothman ***@***.***> wrote:
PR welcome, @skeller88 <https://github.com/skeller88>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16638 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKAKAVLVJZVK3ISEJQCHUDRKPSZPANCNFSM4LBLDTSA>
.
|
Quick question: are there any plans to support categorical features with IterativeImputer? The original MICE implementation (paper) supports this. I did some testing and basic functionality can be achieved by allowing the The trickier part is handling pre-processing steps to those estimators. If some of the features are categorical, they would need to be OneHot encoded between the initial imputation step (which fills in the missing values) and the iterative estimator fitting/predicting. Since The other issue is convergence. I think there is no logical way to quantify convergence from a single |
Describe the workflow you want to enable
Thank you for all the work that's been done on IterativeImputer. I'm excited to use it. I see that it's still in the experimental stage, which makes me hesitant to use it in production code for two reasons:
So my questions are:
Describe your proposed solution
It would be nice to have more details in the IterativeImputer documentation around what assumptions we can rely on about the imputer moving forward, and what assumptions we cannot.
Describe alternatives you've considered, if relevant
Additional context
The text was updated successfully, but these errors were encountered: