Skip to content

NimbusML's dot_export_pipeline for c# #2433

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

Closed
nsulikowski opened this issue Feb 6, 2019 · 6 comments
Closed

NimbusML's dot_export_pipeline for c# #2433

nsulikowski opened this issue Feb 6, 2019 · 6 comments
Labels
API Issues pertaining the friendly API

Comments

@nsulikowski
Copy link

How can I access the list of estimators inside a pipeline?
I can see it as _estimators in the "Non-Public" area of the Locals window when I debug.
I'm trying to display the pipeline graphically (from c#) similar to the way NimbusML does

from nimbusml.utils.exports import dot_export_pipeline
dot_vis = dot_export_pipeline(pipeline, stream)
print(dot_vis)

I'm stuck at how to navigate the pipeline.

@Ivanidzo4ka
Copy link
Contributor

Any EstimatorChain is IEnumerable<IEstimator> so you can iterate over them.
I'm a bit struggling to understand what exactly you mean (probably because I have limited experience with Nimbus). Can you provide code snippet of what you doing and what you is your expected result?

@Ivanidzo4ka Ivanidzo4ka added the need info This issue needs more info before triage label Feb 6, 2019
@nsulikowski
Copy link
Author

nsulikowski commented Feb 6, 2019 via email

@Ivanidzo4ka Ivanidzo4ka added API Issues pertaining the friendly API and removed need info This issue needs more info before triage labels Feb 6, 2019
@Ivanidzo4ka
Copy link
Contributor

My bad I was thinking about TransformerChain which is IEnumarable<ITransformer> and I expect it to be same for EstimatorChain.

@TomFinley any chance you aware why @Zruty0 implemented TransformerChain as IEnumerable but didn't do that for EstimatorChain? Does it sound like API flaw for you?

@TomFinley
Copy link
Contributor

TomFinley commented Feb 7, 2019

Maybe, except, I can see a practical reason why one might want to iterate over ITransformer, I don't see a reason why one would want to iterate over IEstimator.

There's also a question I have about this. In our world, models are transformers... that is, they are the result of fitting an estimator, you don't get estimators out of them. (I.e., IEstimator produces ITransformer, but you'll note ITransformer does not produce IEstimator.) Any operations over transformers cannot produce estimators out of them, so I don't think in any scenario you can get an estimator chain out of a transformer chain.

I am also not a Nimbus expert, but what that function looks like is it takes a model and attempts to do a "code export" of the model... e.g., if you have a linear model, it might write out some easily cut/pastable code that performs that evaluation. It seems to be working via our ICanSaveAsCode interface, which has nothing to do with estimators. So I am fairly certain this doesn't do what we think it does.

But someone actually on Nimbus project might be able to provide better answers than this.

@Zruty0
Copy link
Contributor

Zruty0 commented Feb 7, 2019

Hey, someone summoned me! :)

Actually, I think it was my omission: I should've made the estimator chain an enumerable.
The other thing that I think did not realize its potential is the fact that the estimator and transformer chains are generic on the last estimator/transformer. I think just class EstimatorChain: IEstimator<ITransformer> would work just fine.

In documentation examples I struggle to remember a single case where we substantially utilized LastTransformer / LastEstimator.

@harishsk
Copy link
Contributor

@nsulikowski Please reopen the issue if your question has not been answered.

@ghost ghost locked as resolved and limited conversation to collaborators Mar 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
API Issues pertaining the friendly API
Projects
None yet
Development

No branches or pull requests

5 participants