-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Fixing ModelParameter discrepancies #2968
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
Conversation
@@ -66,7 +66,7 @@ public Arguments() | |||
// estimator, as opposed to a regular trainer. | |||
var trainerEstimator = new LogisticRegressionMulticlassClassificationTrainer(env, LabelColumnName, FeatureColumnName); | |||
return TrainerUtils.MapTrainerEstimatorToTrainer<LogisticRegressionMulticlassClassificationTrainer, | |||
MulticlassLogisticRegressionModelParameters, MulticlassLogisticRegressionModelParameters>(env, trainerEstimator); | |||
LogisticRegressionMulticlassModelParameters, LogisticRegressionMulticlassModelParameters>(env, trainerEstimator); |
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.
We can NOT swap them. Logistic regression is never a multiclass classification model while multi-class logistic regression is an alternative name of multinomial logistic regression. Can you revert this change? I will handle this in my issue #1100. I am refactorizing it. #Resolved
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.
One alternative name we can use is SoftmaxRegression (also mentioned in wikipedia link above).
While refactoring, could you fix the name of the trainer estimator for this as well.
I will revert this, and wait for your refactoring PR. Sounds good ?
In reply to: 265806976 [](ancestors = 265806976)
Codecov Report
@@ Coverage Diff @@
## master #2968 +/- ##
==========================================
+ Coverage 72.35% 72.35% +<.01%
==========================================
Files 803 803
Lines 143296 143296
Branches 16155 16155
==========================================
+ Hits 103675 103679 +4
+ Misses 35194 35191 -3
+ Partials 4427 4426 -1
|
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.
LGTM.
@@ -24,16 +24,16 @@ | |||
OlsTrainer.LoadNameValue, | |||
OlsTrainer.ShortName)] | |||
|
|||
[assembly: LoadableClass(typeof(OrdinaryLeastSquaresRegressionModelParameters), null, typeof(SignatureLoadModel), | |||
[assembly: LoadableClass(typeof(OlsModelParameters), null, typeof(SignatureLoadModel), |
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.
OlsModelParameters [](start = 32, length = 18)
So, general .NET naming guidelines seem to suggest that we avoid acronyms. That is, OrdinaryLeastSquaresRegressionModelParameters
is right, and OlsTrainer
is wrong. Similar with PCA. Have we made a conscious decision to discard the .NET guidelines in this case? If we have, could I see where that discussion happened so I can better understand the rationale? It is not in the linked issue, but may have occurred somewhere else.Thanks. #Resolved
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.
I think the discussion is in this thread: #2762 #Resolved
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.
The summary is here : #2762 (comment)
This came out from suggestion from @sfilipi and @eerhardt .
"For some trainers estimators it is OK to use acronyms for {AlgoName} . This is typically when (a) the expanded name doesn't provide more value to typical users than the acronym or (b) the names becomes too long (c) the acronym is unique in the field." #Resolved
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.
|
||
[assembly: LoadableClass(typeof(void), typeof(NaiveBayesTrainer), null, typeof(SignatureEntryPointModule), NaiveBayesTrainer.LoadName)] | ||
|
||
namespace Microsoft.ML.Trainers | ||
{ | ||
public sealed class NaiveBayesTrainer : TrainerEstimatorBase<MulticlassPredictionTransformer<MulticlassNaiveBayesModelParameters>, MulticlassNaiveBayesModelParameters> | ||
public sealed class NaiveBayesTrainer : TrainerEstimatorBase<MulticlassPredictionTransformer<NaiveBayesModelParameters>, NaiveBayesModelParameters> |
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.
NaiveBayesTrainer [](start = 24, length = 17)
Why does NaiveBayesTrainer
not have Multiclass
or MulticlassClassification
in its name? #Resolved
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.
NaiveBayes is a very general probabilistic technique, and could be applied to many different tasks, so I don't understand the rational for removing the task from its name?
In reply to: 266106131 [](ancestors = 266106131)
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.
- {TypeOfTask} is added only only when the algorithm supports multiple kinds of tasks . When added, we will spell out each task fully. #Resolved
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.
We renamed it as per the discussion here.
• {TypeOfTask} is added only only when the algorithm supports multiple kinds of tasks . When added, we will spell out each task fully.
Do u have any suggestions ?
In reply to: 266107249 [](ancestors = 266107249,266106131)
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.
My concern is that if we add this algorithm for binaryclassification
it would require a breaking change to add Multiclass
to the name NaiveBayes
. I think that the above guideline works well when the algorithm can only be applied to one learning task. But this algorithm can be applied at least to binary and multiclass so I would suggest to add MulticlassClassification
to its name, similarly for the ModelParameters
.
In reply to: 266136420 [](ancestors = 266136420,266107249,266106131)
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.
I see. Currently in ML.NET we only have NaiveBayes under the MulticlassClassification
MLContext
So your concern is about a possible breaking change in the future if we want to add NaiveBayes inside the BinaryClassification
MLContext ? Would we ever want to do that ?
In reply to: 266138507 [](ancestors = 266138507,266136420,266107249,266106131)
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 that was my concern, maybe @[email protected] has an opinion about this?
In reply to: 266143059 [](ancestors = 266143059,266138507,266136420,266107249,266106131)
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.
@TomFinley . Would be great to get your thoughts on this. #Resolved
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.
I would keep multiclass on NaiveBayes too.
In reply to: 266143921 [](ancestors = 266143921,266143059,266138507,266136420,266107249,266106131)
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.
Looks like we favor naming it NaiveBayesMulticlass. Updating accordingly.
In reply to: 266568218 [](ancestors = 266568218,266143921,266143059,266138507,266136420,266107249,266106131)
@@ -49,7 +49,7 @@ internal FastForestOptionsBase() | |||
} | |||
} | |||
|
|||
public sealed class FastForestClassificationModelParameters : | |||
public sealed class FastForestMulticlassModelParameters : |
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.
FastForestMulticlassModelParameters [](start = 24, length = 35)
thank you for not making it FastForestMulticlassClassificationModelParameters :) #WontFix
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.
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.
Thanks @abgoswam !
@@ -171,7 +171,7 @@ private protected override SchemaShape.Column[] GetOutputColumnsCore(SchemaShape | |||
/// <summary> | |||
/// The model parameters class for Binary Classification GAMs | |||
/// </summary> | |||
public sealed class BinaryClassificationGamModelParameters : GamModelParametersBase, IPredictorProducing<float> | |||
public sealed class GamBinaryModelParameters : GamModelParametersBase, IPredictorProducing<float> |
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.
BinaryClassification
?
Do we need to put Classification
in the name? We do everywhere else. #Resolved
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.
For ModelParameters we do not. Please see the other comment.
In reply to: 266626783 [](ancestors = 266626783)
|
||
namespace Microsoft.ML.Trainers | ||
{ | ||
public sealed class NaiveBayesTrainer : TrainerEstimatorBase<MulticlassPredictionTransformer<MulticlassNaiveBayesModelParameters>, MulticlassNaiveBayesModelParameters> | ||
public sealed class NaiveBayesMulticlassTrainer : TrainerEstimatorBase<MulticlassPredictionTransformer<NaiveBayesMulticlassModelParameters>, NaiveBayesMulticlassModelParameters> |
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.
NaiveBayesMulticlassTrainer
=> NaiveBayesMulticlassClassificationTrainer
? Why are we dropping Classification
from these names? #Resolved
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.
as noted in the bug description, it seems for ModelParameters we are consistent in not using the word "Classification" . I am following the same convention in this PR.
Example:
- LinearBinaryModelParameters
- FastTreeBinaryModelParameters
I don't think we have solved the "Classification" debate completely yet #2623
Here is my observation :
- For Trainers, we use "Classification"
- For ModelParameters, we do not use "Classification"
In reply to: 266627123 [](ancestors = 266627123)
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.
For Trainers, we use "Classification"
For ModelParameters, we do not use "Classification"
Why is this a valid policy? #Resolved
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.
I cannot claim its a "valid" policy, but one observation I have is that
- we do not use "Classification" anywhere for ModelParameters
- CalibratedModelParametersBase
- LinearBinaryModelParameters
- in some cases it leads to long names e.g.
FastForestMulticlassClassificationModelParameter
We have 2 options:
A. Follow the naming convention used by Trainers
i.e. "<>BinaryClassification" and "MulticlassClassification" uniformly.
B. Not use "Classification" for ModelParameters .
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.
Fixes #2938
Couple of notes:
PR follows naming convention used by other ModelParameter types in the codebase
Binary
,Regression
orMulticlass
ModelParameter types do not use the word
Classification
in the {TypeOfTask} . PR follows that convention.EDIT : MulticlassLogisticRegressionModelParameters is being refactored by separate issue #1100 . SO not fixing that in this PR