You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Estimators that are instantiated through MAML without specifying a weightcolumn are instead created with default weightcolumn named "Weights".
More details:
The constructor for estimator objects that is used by MAML takes an Arguments object, which has a weight column name that defaults to "Weights". To be precise it defaults to an Optional with implicit value of "Weights".
When we instantiate the estimator through that constructor, we need to pass a SchemaShape.Column object to the base class TrainerEstimatorBase. This column is in most cases constructed with a method that takes the column name as specified in the Arguments object. As the default value in the Arguments object is not null, it is "Weights", this method does not return null, but returns a new SchemaShape.Column named Weights.
The rational:
The new API's rational is as follows:
the user needs to specify a weight column name, if the name is not null we check the presence of the column
if the user does not define a weight column name (it is null), we assume there is no weight column
The old MAML's rational:
same as above
if the user does not specify a weight column name:
if there is a column named "Weights" it will be taken as the weights column automatically
if there is no column name "Weights", we assume that there is no weight column
What we have to do:
We have to fix the current instantiation of estimators through MAML, and decide if we want to continue using a different behavior for the command line and the C# API.
The text was updated successfully, but these errors were encountered:
I just realized that we have not done this and it has implications for our public surface. This must be done soon. We currently have a situation where if there happens to be a column named Weight, there is no way to have unweighted training, which is really bad!!
@eerhardt and @ganik have context on this. It also reflects something I was talking about with @vinodshanbhag earlier today where I (wrongly) claimed that it was possible to not set weighted training in this scenario of the "incidental" `Weight column. I realized when reviewing #2665 that we are still doing this wrong thing.
The behavior should be as @artidoro describes above, that if the weight column is left null, you simply do not have weighted training. If you want weighted training, you must provide the column name to a non-null value.
Estimators that are instantiated through MAML without specifying a weightcolumn are instead created with default weightcolumn named "Weights".
More details:
The constructor for estimator objects that is used by MAML takes an Arguments object, which has a weight column name that defaults to "Weights". To be precise it defaults to an Optional with implicit value of "Weights".
When we instantiate the estimator through that constructor, we need to pass a SchemaShape.Column object to the base class TrainerEstimatorBase. This column is in most cases constructed with a method that takes the column name as specified in the Arguments object. As the default value in the Arguments object is not null, it is "Weights", this method does not return null, but returns a new SchemaShape.Column named Weights.
The rational:
The new API's rational is as follows:
The old MAML's rational:
What we have to do:
We have to fix the current instantiation of estimators through MAML, and decide if we want to continue using a different behavior for the command line and the C# API.
The text was updated successfully, but these errors were encountered: