TrainersName pattern (Discussion)

[Ivanidzo4ka]

#2172 follow up on this one.
So right now we have mix of trainers names.
I want to standardize them.

We have following zoo of naming patterns:
LogisticRegression
SdcaMultiClassTrainer
SgdNonCalibratedBinaryTrainer
LinearSvmTrainer
LightGbmMulticlassTrainer
MulticlassLogisticRegression

My proposal is following:

{AlgoName}(optional){Calibrated/NonCalibrated}{TypeOfTask}Trainer

Where AlgoName is full name without abbreviations (SDCA->StochasticDualCoordinateAscent, Linearsvm ->LinearSupportVectorMachines) with exception of LightGBM.

I would also prefer to explicitly specify TypeOfTask even if algorithm exist only for one type. (Which would create weird abominations like OneVersusAllMulticlassTrainer, but i'm fine with that)

Does that sound good for you?
@sfilipi @TomFinley @eerhardt @yaeldekel

[wschin]

Maybe {AlgoName}{**ModelName**}(optional){Calibrated/NonCalibrated}{TypeOfTask}Trainer?

[Ivanidzo4ka]

What ModelName means? Can you give example?

[wschin]

StochasticGradient-FieldAwareFactorizationMachine-Calibrated-BinaryClassification
AlternatingNewton-FieldAwareFactorizationMachine-Calibrated-BinaryClassification

[abgoswam]

This is also related to #2172 . The trainer estimator Class names we finally decide upon should also match the corresponding MLContext names

So if a user has to specify an SDCA binary trainer with advanced options, they would have to say something like :

// Pipeline.
var pipeline =
ml.BinaryClassification.Trainers.StochasticDualCoordinateAscentNonCalibratedBinaryTrainer(
new StochasticDualCoordinateAscentNonCalibratedBinaryTrainer.Options { NumThreads = 1 }
);

It may be overly verbose. Thoughts ?

[TomFinley]

ml.BinaryClassification.Trainers.StochasticDualCoordinateAscentNonCalibratedBinaryTrainer(
new StochasticDualCoordinateAscentNonCalibratedBinaryTrainer.Options { NumThreads = 1 }
);

It may be overly verbose. Thoughts ?

Right. It's not even StochasticDualCoordinateAscentNonCalibratedBinaryTrainer, if we also take the advice to incorporate the type of model it becomes, I think, StochasticDualCoordinateAscentLinearNonCalibratedBinaryTrainer. Likewise with AlternatingNewtonFieldAwareFactorizationMachineCalibratedBinaryClassificationTrainer. I think being principled is fine, but this is clearly nuts. I also don't see any harm in OneVersusAllTrainer.

I think naming things calibrated or not is fine if there is actually a distinction. But, I would pick one to identify as being calibrated or uncalibrated. If a class of models always produces calibrated or always non-calibrated models, no need to call attention to it. In any case it will be obvious from the return value and the generic parameters.

LogisticRegressionBinaryClassificationTrainer might be fine. That's not too long.

I know we're asking for hard and fast rules, but I think this is one of those cases where you just have to accept that if having a uniform procedure for naming would lead to a ridiculous situations like identifier names greater than 80 characters, we need to accept that a slightly irregular situation is better than being perfectly regular. If it's any consolation, sklearn gets by just fine without having these elaborate, byzantine names.

[eerhardt]

(thoughts from a non-data scientist):

1. Some of these names sound like they should be options/parameters instead of whole new methods/classes. Especially Calibrated vs. Non-calibrated.
2. For the method names, there is no point in having the TypeOfTask nor the Trainer suffix. We are already in the context of "task" and "trainers" by the time we've reached the method: mlContext.BinaryClassification.Trainers.StochasticDualCoordinateAscent(

[abgoswam]

Here's a proposal

• For MLContext name, we keep only the {AlgoName}. As @eerhardt noted above, by the time we reach the method we already have all the necessary info, and do not have to repeat the same again.

• For the Class name, we use the patter {AlgoName}(optional){Calibrated/NonCalibrated}{TypeOfTask}Trainer. The class name is slightly more verbose.

Note : that users would would have to use the class name only when they want to use the trainer estimators with advanced Options.

• It does mean that the exact match of MLContext name and Class name desired in The trainer name types should follow the names used in the contexts #2172 will not be there. There will be a prefix match of the {AlgoName}

(non-standard usage currently)	Proposed MLContext Name	Proposed Class Name
LightGbmRegressorTrainer	LightGbm	LightGbmRegressionTrainer
LightGbmBinaryTrainer	LightGbm	LightGbmBinaryClassificationTrainer
LightGbmRankingTrainer	LightGbm	LightGbmRankingTrainer
LightGbmMulticlassTrainer	LightGbm	LightGbmMulticlassClassificationTrainer
FastTreeBinaryClassificationTrainer	FastTree	FastTreeBinaryClassificationTrainer
FastTreeRegressionTrainer	FastTree	FastTreeRegressionTrainer
FastTreeRankingTrainer	FastTree	FastTreeRankingTrainer
FastTreeTweedieTrainer	FastTreeTweedie	FastTreeTweedieRegressionTrainer
FastForestRegression	FastForest	FastForestRegressionTrainer
FastForestClassification	FastForest	FastForestBinaryClassificationTrainer
MatrixFactorizationTrainer	MatrixFactorization	MatrixFactorizationRecommendationTrainer
BinaryClassificationGamTrainer	GeneralizedAdditiveModel	GeneralizedAdditiveModelBinaryClassificationTrainer
RegressionGamTrainer	GeneralizedAdditiveModel	GeneralizedAdditiveModelRegressionTrainer
LogisticRegression	LogisticRegression	LogisticRegressionBinaryClassificationTrainer
MulticlassLogisticRegression	LogisticRegression	LogisticRegressionMulticlassClassificationTrainer
AveragedPerceptronTrainer	AveragedPerceptron	AveragedPerceptronBinaryClassificationTrainer
LinearSvmTrainer	LinearSvm	LinearSvmBinaryClassificationTrainer
OnlineGradientDescentTrainer	OnlineGradientDescent	OnlineGradientDescentRegressionTrainer
PoissonRegression	PoissonRegression	PoissonRegressionTrainer
SdcaBinaryTrainer	StochasticDualCoordinateAscent	StochasticDualCoordinateAscentBinaryClassificationTrainer
SdcaNonCalibratedBinaryTrainer	StochasticDualCoordinateAscentNonCalibrated	StochasticDualCoordinateAscentNonCalibratedBinaryClassificationTrainer
SdcaMultiClassTrainer	StochasticDualCoordinateAscent	StochasticDualCoordinateAscentMulticlassClassificationTrainer
SdcaRegressionTrainer	StochasticDualCoordinateAscent	StochasticDualCoordinateAscentRegressionTrainer
KMeansPlusPlusTrainer	KMeans	KMeansPlusPlusClusteringTrainer
OrdinaryLeastSquaresRegressionTrainer	OrdinaryLeastSquares	OrdinaryLeastSquaresRegressionTrainer

CurrentName	Proposed MLContext Name	Proposed Class Name
FieldAwareFactorizationMachineBinaryClassificationTrainer	FieldAwareFactorizationMachine	FieldAwareFactorizationMachineBinaryClassificationTrainer
SymbolicStochasticGradientDescentClassificationTrainer	SymbolicStochasticGradientDescent	SymbolicStochasticGradientDescentBinaryClassificationTrainer

Base Class	Proposed New Name
SdcaTrainerBase (base class)	StochasticDualCoordinateAscentTrainerBase
LbfgsTrainerBase (base class)	LbfgsTrainerBase
GamTrainerBase (base class)	GeneralizedAdditiveModelTrainerBase

EDITS Proposed:

• {AlgoName} for KMeans in MLContext should be KMeansPlusPlus.

[eerhardt]

That proposal looks good @abgoswam. Here are some questions/comments:

1. When do we decide when we should use acronyms and when we don't? We have Svm, Gbm and Lbfgs above. But some things that use acronyms elsewhere are spelled out - for example we have a SymSgdNative assembly, but are spelling out SymbolicStochasticGradientDescent above.

2. KMeans vs. KMeansPlusPlusClusteringTrainer - what is the AlgoName? KMeans or KMeansPlusPlus? We should probably be consistent here.

[abgoswam]

1. For acronyms, the table above uses acronyms when the acronym is itself seems to be more standard than using the full name

• LightGbm comes from the name of the library itself
• SVM also is a very standard acronym
• For SymSGD is less convincing . While SGD is standard acronym but Sym isnt. We can either rename it to SymbolicSGD or use the full name SymbolicStochasticGradientDescent . Do we have a preference ?

2. The AlgoName should be KMeansPlusPlus (thats the algo our internal repo points to) . Thanks for pointing is out. I have noted this in the "Edits Proposed" section of the table.

[eerhardt]

I don't have a huge preference. I was mostly just trying to get what the policy is. If we go by "This is the algo's standard name - ex. LightGBM", then I think that is a fine policy.

[shmoradims]

FYI, the Proposed MLContext Names above, are 90+% what we already have today (#2522). MLContext Names pattern for acronyms is spelled out with the exception of LightGbm. I think MLContext names look good as is, but I'll be open to changing the acronym spelling rule, in favor of making the trainer names shorter. I mean StochasticDualCoordinateAscentNonCalibratedBinaryClassificationTrainer is just mind-numbing. Now that we have better documentation any developer can hover over the name and know what Sdca, Sgd, or Svm is.

We also need to standardize the acronyms casing between ALL-CAPS and Pascal (SVM vs Svm). It's different for different acronyms and trainer vs mlcontext names.

From user perspective it would be helpful to have the same <Trainer_API_Name> in both MLContext and Trainer class names below:

• MlContext: MLContext.BinaryClassification.Trainers.<Trainer_API_Name>
• Trainer class name: <Trainer_API_Name> BinaryClassificationTrainer

[TomFinley]

Our preference has been to rely on the "brand" name of something. E.g.: LightGBM I think should rename as is, since LightGBM is an established name.

SymSGD is not a brand name, in fact, publicly it seems like they prefer the name "Parasail" and "Project Parade" if I look at the people behind the algorithm. So I might prefer SymbolicSGD here, since unlike light GBM this does not seem to be externally branded as we internally branded it, back during the initial collaboration. (As opposed to LightGBM, which was released with that name.)

SVM and LBFGS are harder ones. These are names that are well understood in the community, to the point where it would possibly do more harm than good to spell them out (especially L-BFGS).

I am pretty comfortable with SVM, but I'd also be comfortable spelling out "Support Vector Machine." It's short enough and clear enough. So, do as you will here.

I am less comfortable with L-BFGS, but in both directions. I also feel like spelling that guy out would do more harm than good... If it comes down to it I suppose I can live with Lbfgs. I also don't have a clear answer here -- that one just seems tough, but I think the least harmful thing is to keep Lbfgs, as obnoxious as that is. The idea of a class named LimitedMemoryBroydenFletcherGoldfarbShannoTrainerBase wearies me. In a more ideal world we'd find an even better name, but if we haven't in however many years I don't think we're going to magically come up with the perfect name right now. I wouldn't object though if it somehow magically came to us, of course. 😄

My opinions are not strong, just thought I'd register them though.

[eerhardt]

We also need to standardize the acronyms casing between ALL-CAPS and Pascal (SVM vs Svm)

The general guidance from a .NET API perspective is to use PascalCasing for acronyms over two letters, and for two-letter acronyms both letters are capitalized. See https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions.

For LightGBM I can imagine us sticking with that casing as that appears to be its "proper name": ex. https://lightgbm.readthedocs.io/

[abgoswam]

Thanks folks for the comments. Based on the feedback I am listing down the learners where we will use acronyms (with PascalCasing for acronyms over two letters)

(non-standard usage currently)	Proposed MLContext Name	Proposed Class Name
LightGbmRegressorTrainer	LightGBM	LightGBMRegressionTrainer
LightGbmBinaryTrainer	LightGBM	LightGBMBinaryClassificationTrainer
LightGbmRankingTrainer	LightGBM	LightGBMRankingTrainer
LightGbmMulticlassTrainer	LightGBM	LightGBMMulticlassClassificationTrainer
SymbolicStochasticGradientDescentClassificationTrainer	SymbolicSgd	SymbolicSgdBinaryClassificationTrainer
LinearSvmTrainer	LinearSvm	LinearSvmBinaryClassificationTrainer
LbfgsTrainerBase (keep as is)		LbfgsTrainerBase
RandomizedPcaTrainer	RandomizedPca	RandomizedPcaAnomalyDetectionTrainer

@shmoradims . As noted above there is a prefix match of the {AlgoName} between MLContext name and Class name. So we should be good there.

Next I will go ahead and make the code changes as per the above table + additional suggested edits captured in this table

[Ivanidzo4ka]

We also plan to ship RandomizedPcaTrainer
Would be nice to come up with proper name for it as well.

[abgoswam]

added RandomizedPcaTrainer to the above table (that includes the trainers with acronyms)

Also listing down a few trainers missed above :

(non-standard usage currently)	Proposed MLContext Name	Proposed Class Name
PriorTrainer	Prior	PriorBinaryClassificationTrainer
PairwiseCoupling	PairwiseCoupling	PairwiseCouplingMulticlassClassificationTrainer
OneVersusAll	OneVersusAll	OneVersusAllMulticlassClassificationTrainer
NaiveBayes	NaiveBayes	NaiveBayesMulticlassClassificationTrainer
StochasticGradientDescent	StochasticGradientDescent	StochasticGradientDescentBinaryClassificationTrainer
StochasticGradientDescentNonCalibrated	StochasticGradientDescentNonCalibrated	StochasticDualCoordinateAscentRegressionTrainer

[sfilipi]

I am jumping in this late, but two thoughts:
1- the Trainer part of the name is not adding any information. It is unnecessary, since it will be used from the mlContext, where all the registered types are trainers, and trainer appears in the chain of objects.
2- the task part is unnecessary too, again given how they get used through the mlContext, where the task is already selected.

See what we get with the above proposal when we use them:

ml.Regression.Trainers.StochasticDualCoordinateAscentRegressionTrainer

notice the trainers and regression repetition.

the current:

ml.Regression.Trainers.StochasticDualCoordinateAscent ( new StochasticDualCoordinateAscent.Options)

looks a lot better..

I would leave the Trainer part out, and the task part out (unless we have per task), and fix whatever name is not just the plain short algorithm name.

ex: not LightGBMMulticlassClassificationTrainer but just 'LightGBMMulticlassClassification'.

The examples

scikit names are short too.

cc @markusweimer

[wschin]

@sfilipi, do you need LightGBMMulticlassClassification for LightGBMMulticlassClassificationTrainer? Or just LightGBM?

[markusweimer]

I have a question: Are we discussing the names of the factory methods in MLContext or the names of the underlying classes?

[abgoswam]

Proposal above : #2762 (comment)

@markusweimer . The proposal above discussed both "Proposed MLContext name" and "Proposed Class name" .

@sfilipi . We already took into consideration that we do not need to repeat the info already present in the MLContext chain. Hence the tables above shows the "Proposed MLContext name" and "Proposed Class name" .

• The "Proposed MLContext Names" are succinct.

• The "Proposed Class Name" follows the pattern {AlgoName}(optional){Calibrated/NonCalibrated}{TypeOfTask}Trainer. Here we include {TypeOfTask} and suffix Trainer in the class name because the underlying class is agnostic of MLContext.

• I do not think we can drop {TypeOfTask} from the Class name because we have some trainers (e.g. LogisticRegrerssion) that work for both binary and multiclass classification . Hence the need to distingusigh between LogisticRegressionBinaryClassificationTrainer and LogisticRegressionMulticlassClassificationTrainer in the class name. The MLContext name would just be LogisticRegression

• Are you suggesting we drop "Trainer" from the Class name ?

[sfilipi]

The usage of the underlying class, from the user prospective, will be from the actual extension of the mlContext, mostly to specify the options. In this context, the name trainer adds no info, and the task adds no info.

Now because they are separate types, they need their names distict, so we need some sort of identifier for the trainers that we have for more than one task (SDCA, FastTree, LightGBM). For those cases we can keep the task in the name, for the others drop it..

To summarize, to avoid verbosity from the user prospective:

• drop trainer from the name everywhere
• keep the task only when needed to resolve ambiguity.

[sfilipi]

@sfilipi, do you need LightGBMMulticlassClassification for LightGBMMulticlassClassificationTrainer? Or just LightGBM?

for the extensions, just the algorithm (LightGBM).
For the trainer (the type extending the ITrainerEstimator) Algo+Task if needed to resolve ambiguity. Drop the task for all the learners that solve just one task..

My rationale is just.. keep them as short as it makes sense..

[eerhardt]

drop trainer from the name everywhere

I thought we decided in #1318 to use the suffix:

Should be named ActionPerformingEstimator, or AlgorithmNameTrainer

[sfilipi]

@eerhardt when we were discussing #1318 the shape of the API was different; the Trainer names were not user facing, we had that delegate over the Arguments class that had a short name. The AlgorithmNameTrainer was mostly for our codebase uniformity and documentation, but didn't appear in the API as much, now it does.

[abgoswam]

Based on the discussion above, here is the convention we are following for trainer estimator names.

• For MLContext name, we keep only the {AlgoName}.

• For the Class name, we use the pattern : {AlgoName}(optional){Calibrated/NonCalibrated}(optional){TypeOfTask}

  • {Calibrated/NonCalibrated} is added only when the algorithm supports both forms of calibration. When added, we will spell out each form fully.

  • {TypeOfTask} is added only only when the algorithm supports multiple kinds of tasks . When added, we will spell out each task fully. e.g. LogisticRegressionBinaryClassification LogisticRegressionMulticlassClassification

• There are 5 trainers estimators where we feel it is OK to use acronyms for {AlgoName}

  • using long names just becomes too long.
    • Sdca instead of StochasticDualCoordinateAscent
    • Lbfgs instead of LimitedMemoryBroydenFletcherGoldfarbShanno
  • acronym is an established name
    • LightGbm
    • PCA (in RandomizedPca)
    • SVM (in LinearSvm)

• When using acronyms for {AlgoName} we will follow .NET convention i.e. PascalCasing for acronyms over two letters, and for two-letter acronyms both letters are capitalized. See https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions.

---

Based on the above, here is the list of trainer estimator names we expose for V1.0

(non-standard usage currently)	Proposed MLContext Name	Proposed Class Name
FastTreeBinaryClassificationTrainer	FastTree	FastTreeBinaryClassification
FastTreeRegressionTrainer	FastTree	FastTreeRegression
FastTreeRankingTrainer	FastTree	FastTreeRanking
FastTreeTweedieTrainer	FastTreeTweedie	FastTreeTweedie
FastForestRegression	FastForest	FastForestRegression
FastForestClassification	FastForest	FastForestBinaryClassification
MatrixFactorizationTrainer	MatrixFactorization	MatrixFactorization
BinaryClassificationGamTrainer	GeneralizedAdditiveModel	GeneralizedAdditiveModelBinaryClassification
RegressionGamTrainer	GeneralizedAdditiveModel	GeneralizedAdditiveModelRegression
LogisticRegression	LogisticRegression	LogisticRegressionBinaryClassification
MulticlassLogisticRegression	LogisticRegression	LogisticRegressionMulticlassClassification
AveragedPerceptronTrainer	AveragedPerceptron	AveragedPerceptron
OnlineGradientDescentTrainer	OnlineGradientDescent	OnlineGradientDescent
PoissonRegression	PoissonRegression	PoissonRegression
KMeansPlusPlusTrainer	KMeansPlusPlus	KMeansPlusPlus
OrdinaryLeastSquaresRegressionTrainer	OrdinaryLeastSquares	OrdinaryLeastSquares
PriorTrainer	Prior	Prior
PairwiseCoupling	PairwiseCoupling	PairwiseCoupling
OneVersusAll	OneVersusAll	OneVersusAll
NaiveBayes	NaiveBayes	NaiveBayes
StochasticGradientDescent	StochasticGradientDescentCalibrated	StochasticGradientDescentCalibrated
StochasticGradientDescentNonCalibrated	StochasticGradientDescentNonCalibrated	StochasticGradientDescentNonCalibrated
FieldAwareFactorizationMachineBinaryClassificationTrainer	FieldAwareFactorizationMachine	FieldAwareFactorizationMachine
SymbolicStochasticGradientDescentClassificationTrainer	SymbolicStochasticGradientDescent	SymbolicStochasticGradientDescent

Trainers estimators where we feel it is OK to use acronyms

(non-standard usage currently)	Proposed MLContext Name	Proposed Class Name
LightGbmRegressorTrainer	LightGbm	LightGbmRegression
LightGbmBinaryTrainer	LightGbm	LightGbmBinaryClassification
LightGbmRankingTrainer	LightGbm	LightGbmRanking
LightGbmMulticlassTrainer	LightGbm	LightGbmMulticlassClassification
LinearSvmTrainer	LinearSvm	LinearSvm
RandomizedPcaTrainer	RandomizedPca	RandomizedPca
SdcaBinaryTrainer	SdcaCalibrated	SdcaCalibratedBinaryClassification
SdcaNonCalibratedBinaryTrainer	SdcaNonCalibrated	SdcaNonCalibratedBinaryClassification
SdcaMultiClassTrainer	Sdca	SdcaMulticlassClassification
SdcaRegressionTrainer	Sdca	SdcaRegression

Base classes

Base Class	Proposed New Name
SdcaTrainerBase (base class)	SdcaTrainerBase
LbfgsTrainerBase (base class)	LbfgsTrainerBase
GamTrainerBase (base class)	GeneralizedAdditiveModelTrainerBase

@sfilipi @eerhardt

[eerhardt]

There are 5 trainers estimators where we feel it is OK to use acronyms for {AlgoName}
using long names just becomes too long.

I would instead phrase this as "The expanded name doesn't provide more value to typical users than the acronym, the names becomes too long, and the acronym is unique in the field".

---

I wonder if we could still include the Trainer suffix now with this updated proposal. Class names are typically nouns. Method names are typically verbs. Many of the above proposed names have the class names and the method names the same:

(non-standard usage currently)	Proposed MLContext Name	Proposed Class Name
PriorTrainer	Prior	Prior
PairwiseCoupling	PairwiseCoupling	PairwiseCoupling
OneVersusAll	OneVersusAll	OneVersusAll
NaiveBayes	NaiveBayes	NaiveBayes

[sfilipi]

I like the shorter names.

personally i'd abbreviate the followings too:

StochasticGradientDescent -> SGD.
(https://en.wikipedia.org/wiki/Stochastic_gradient_descent )

GeneralizedAdditiveModel -> GAM
(https://en.wikipedia.org/wiki/Generalized_additive_model)

Ordinary Least Squares
https://en.wikipedia.org/wiki/Ordinary_least_squares

Let's not abbreviate in the documentation, though cc @shmoradims

@markusweimer do you think those are reasonable, compared to other frameworks?

Just to summarize, main benefit of reverting back to acronyms is that we go from this:

ml.Regression.Trainers.StochasticDualCoordinateAscent ( new StochasticDualCoordinateAscent.Options{ ...Options here })

to

ml.Regression.Trainers.Sdca ( new SdcaRegression.Options{ ... Options here })

[sfilipi]

@eerhardt even if we add the Trainer name to the classes the method names remain still names.
I am fine to add if for distinction, if we start using the acronyms.

[abgoswam]

Summary :

• For MLContext name, we keep the {AlgoName}(optional){Calibrated/NonCalibrated}

  • {Calibrated/NonCalibrated} is added only when the algorithm supports both forms of calibration. When added, we will spell out each form fully.
    • mlContext.BinaryClassification.Trainers.SdcaCalibrated
    • mlContext.BinaryClassification.Trainers.SdcaNonCalibrated

• For the Class name, we use the pattern : {AlgoName}(optional){Calibrated/NonCalibrated}(optional){TypeOfTask}Trainer

  • {Calibrated/NonCalibrated} is added only when the algorithm supports both forms of calibration. When added, we will spell out each form fully.

    • SdcaCalibratedBinaryClassificationTrainer
    • SdcaNonCalibratedBinaryClassificationTrainer

  • {TypeOfTask} is added only only when the algorithm supports multiple kinds of tasks . When added, we will spell out each task fully.

    • LogisticRegressionBinaryClassification
    • LogisticRegressionMulticlassClassification

• 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.

  • Example
    • SGD : https://en.wikipedia.org/wiki/Stochastic_gradient_descent
    • GAM : https://en.wikipedia.org/wiki/Generalized_additive_model
    • OLS : https://en.wikipedia.org/wiki/Ordinary_least_squares
    • PCA : https://en.wikipedia.org/wiki/Principal_component_analysis
    • SVM : https://en.wikipedia.org/wiki/Support-vector_machine
    • LightGbm

• When using acronyms for {AlgoName} we will follow .NET convention i.e. PascalCasing for acronyms over two letters, and for two-letter acronyms both letters are capitalized.

  • See https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions.