Skip to content

Estimators and their catalog extensions should have matching names #2853

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
artidoro opened this issue Mar 5, 2019 · 1 comment
Closed
Labels
API Issues pertaining the friendly API

Comments

@artidoro
Copy link
Contributor

artidoro commented Mar 5, 2019

In #2827, one of the items is to make sure the estimators and their catalog extensions have matching names. Like in trainers, we should keep the suffix estimator only in the estimator name, and remove it from the catalog extension, something like the following:

NameEstimator Name(...)

The question now is: How do we reconcile the names and which convention should we follow?

Most estimator names follow the convention: ActionPerformingEstimator, while in the catalog usually we use the convetion: PerformAction.

Some examples are:

Estimator Name Catalog Name
KeyToBinaryVectorMappingEstimator MapKeyToBinaryVector
MutualInformationFeatureSelectingEstimator SelectFeaturesBasedOnMutualInformation
CountFeatureSelectingEstimator SelectFeaturesBasedOnCount
... ...

cc/ @sfilipi @TomFinley @glebuk @eerhardt @rogancarr @ivanbasov

@artidoro artidoro added the API Issues pertaining the friendly API label Mar 5, 2019
@artidoro
Copy link
Contributor Author

artidoro commented Mar 5, 2019

As per offline discussion, we have concluded that the difference is voluntary. The example given was:

So if I have a class called "CarrotEater", but I have a method that applies it, I'd be surprised if it wasn't named "EatCarrots".

@artidoro artidoro closed this as completed Mar 5, 2019
@ghost ghost locked as resolved and limited conversation to collaborators Mar 23, 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

1 participant