Mass rename of transformers and MLContext extensions for them

[Zruty0]

Let's go over all the existing transforms and make sure that they share the same naming conventions:

• Estimators

  • Should be named ActionPerformingEstimator, or AlgorithmNameTrainer
  • Should be placed in Microsoft.ML.Trainers, Transforms or sub-namespaces if applicable
  • If they take input or output colunms, they should be 'inputColumn' and 'outputColumn', and the outputColumn should be nullable.

• Trainers

  • If they take features/label columns, they should be in the same order (label, features, weights, other), and have defaults.
  • Important parameters should be listed as ctor arguments.
  • Other parameters should be a delegate over advanced settings
    • Generally, trainers should have exactly one constructor. Overload only if necessary.

• Transformers

  • Should be named ActionPerformingTransformer
  • Should be placed in Microsoft.Ml.Transforms or sub-namespaces
  • If they are trainable, they should NOT have a public constructor.
  • If they are NOT trainable, they SHOULD have a public constructor.

[justinormont]

What types of sub-namespaces are we looking for?

For example would we want categories like { Text, Image Normalize, etc }? For example, Microsoft.Ml.Transforms.Text.WordEmbeddingsTransform.

Have we publicly defined the term trainable? Tersely, trainable components take a pass of the data and learns from it, then after being trained it can used. Examples of this include: text featurization (where we take a pass to index the words), label encoding (where we take a pass to index the labels), normalizers (to learn the range of the numbers), and feature selection (to count/learn which features to keep).

[sfilipi]

@Zruty0

If they are trainable, they should NOT have a public constructor.
If they are trainable, they SHOULD have a public constructor.

¯_(ツ)_/¯

[Zruty0]

I updated the comment. @justinormont , yes on the namespaces.

And the explanation of trainable is also accurate, thanks.

[sfilipi]

@Zruty0 one more question, should the transforms currently living in Microsoft.ML.Runtime.Data move to Microsoft.ML.Transforms?

[Zruty0]

They should move out of 'Runtime'. If there is some form of inherent grouping, it may or may not be reflected in sub-namespace, but the root should be Microsoft.ML.Transforms.

[TomFinley]

One thing I wonder if we should make explicit, is if a Transformer is produced by exactly one Estimator, whether it should tend to be named the same as the estimator? That is FooEstimator should tend to produce FooTransformer? Obviously not applicable in the case where a transformer is produced by multiple estimators (e.g., a drop slots transformer can be produced by multiple estimators, a linear model can be produced many ways, etc.)

[Zruty0]

That was the intent, yes.

[justinormont]

Do we have candidate list of the new names?

Current name	New Name
x	x'

Is there a public place where this list can be grown? A wiki like interface could be suitable.

[Zruty0]

@justinormont , I don't think we need to produce a separate list. The old names are sort of incidental, so there is no value in preserving them for posterity. The new names will be reflected in the documentation. The renaming itself is abundantly visible on the pull request.