-
Notifications
You must be signed in to change notification settings - Fork 358
Remove Experiment.default_data_constructor and Experiment.default_data_type #4691
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
|
@esantorella has exported this pull request. If you are a Meta employee, you can view the originating Diff in D89689313. |
…a_type (facebook#4691) Summary: Pull Request resolved: facebook#4691 **Context:** `default_data_constructor` and `default_data_type` are used for a few purposes: 1. Determining the type of empty data 2. Determining the type of data that results from combining multiple `Data`s 3. Validating that observations passed match the `default_data_type` on the experiment Now that we have reduced our data classes down to just `Data` and `MapData`, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data. This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column. **This PR:** 1. Makes empty data `Data` 2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData. 2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column 3. Removes some validations that are no longer necessary **Some TODOs for follow-up diffs:** * Remove `Metric.data_constructor` (if needed, replacing it with a boolean attribute indicating whether a progression will be produced) * Convert some `Metric` methods such as `_unwrap_experiment_data` into static methods or move them off `Metric` entirely now that they do not reference the `data_constructor` attribute Differential Revision: D89689313
1469d40 to
6b85ffc
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4691 +/- ##
==========================================
- Coverage 96.69% 96.69% -0.01%
==========================================
Files 580 580
Lines 60714 60694 -20
==========================================
- Hits 58708 58688 -20
Misses 2006 2006 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…a_type (facebook#4691) Summary: Pull Request resolved: facebook#4691 **Context:** `default_data_constructor` and `default_data_type` are used for a few purposes: 1. Determining the type of empty data 2. Determining the type of data that results from combining multiple `Data`s 3. Validating that observations passed match the `default_data_type` on the experiment Now that we have reduced our data classes down to just `Data` and `MapData`, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data. This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column. **This PR:** 1. Makes empty data `Data` 2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData. 2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column 3. Removes some validations that are no longer necessary * Removes `Experiment._default_data_type` * Removes `Experiment.default_data_type` * Removes `Experiment.default_data_constructor` **Some TODOs for follow-up diffs:** * Deprecate or remove `default_data_type` argument to experiment * Remove `Metric.data_constructor` (if needed, replacing it with a boolean attribute indicating whether a progression will be produced) * Convert some `Metric` methods such as `_unwrap_experiment_data` into static methods or move them off `Metric` entirely now that they do not reference the `data_constructor` attribute Reviewed By: lena-kashtelyan Differential Revision: D89689313
6b85ffc to
1505697
Compare
…a_type (facebook#4691) Summary: Pull Request resolved: facebook#4691 **Context:** `default_data_constructor` and `default_data_type` are used for a few purposes: 1. Determining the type of empty data 2. Determining the type of data that results from combining multiple `Data`s 3. Validating that observations passed match the `default_data_type` on the experiment Now that we have reduced our data classes down to just `Data` and `MapData`, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data. This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column. **This PR:** 1. Makes empty data `Data` 2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData. 2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column 3. Removes some validations that are no longer necessary * Removes `Experiment._default_data_type` * Removes `Experiment.default_data_type` * Removes `Experiment.default_data_constructor` **Some TODOs for follow-up diffs:** * Deprecate or remove `default_data_type` argument to experiment * Remove `Metric.data_constructor` (if needed, replacing it with a boolean attribute indicating whether a progression will be produced) * Convert some `Metric` methods such as `_unwrap_experiment_data` into static methods or move them off `Metric` entirely now that they do not reference the `data_constructor` attribute Differential Revision: D89689313 Privacy Context Container: L1307644 Reviewed By: lena-kashtelyan
…a_type (facebook#4691) Summary: Pull Request resolved: facebook#4691 **Context:** `default_data_constructor` and `default_data_type` are used for a few purposes: 1. Determining the type of empty data 2. Determining the type of data that results from combining multiple `Data`s 3. Validating that observations passed match the `default_data_type` on the experiment Now that we have reduced our data classes down to just `Data` and `MapData`, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data. This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column. **This PR:** 1. Makes empty data `Data` 2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData. 2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column 3. Removes some validations that are no longer necessary * Removes `Experiment._default_data_type` * Removes `Experiment.default_data_type` * Removes `Experiment.default_data_constructor` **Some TODOs for follow-up diffs:** * Deprecate or remove `default_data_type` argument to experiment * Remove `Metric.data_constructor` (if needed, replacing it with a boolean attribute indicating whether a progression will be produced) * Convert some `Metric` methods such as `_unwrap_experiment_data` into static methods or move them off `Metric` entirely now that they do not reference the `data_constructor` attribute Differential Revision: D89689313 Privacy Context Container: L1307644 Reviewed By: lena-kashtelyan
…a_type (facebook#4691) Summary: Pull Request resolved: facebook#4691 **Context:** `default_data_constructor` and `default_data_type` are used for a few purposes: 1. Determining the type of empty data 2. Determining the type of data that results from combining multiple `Data`s 3. Validating that observations passed match the `default_data_type` on the experiment Now that we have reduced our data classes down to just `Data` and `MapData`, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data. This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column. **This PR:** 1. Makes empty data `Data` 2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData. 2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column 3. Removes some validations that are no longer necessary * Removes `Experiment._default_data_type` * Removes `Experiment.default_data_type` * Removes `Experiment.default_data_constructor` **Some TODOs for follow-up diffs:** * Deprecate or remove `default_data_type` argument to experiment * Remove `Metric.data_constructor` (if needed, replacing it with a boolean attribute indicating whether a progression will be produced) * Convert some `Metric` methods such as `_unwrap_experiment_data` into static methods or move them off `Metric` entirely now that they do not reference the `data_constructor` attribute Reviewed By: lena-kashtelyan Differential Revision: D89689313
1505697 to
4f8c624
Compare
…a_type (facebook#4691) Summary: **Context:** `default_data_constructor` and `default_data_type` are used for a few purposes: 1. Determining the type of empty data 2. Determining the type of data that results from combining multiple `Data`s 3. Validating that observations passed match the `default_data_type` on the experiment Now that we have reduced our data classes down to just `Data` and `MapData`, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data. This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column. **This PR:** 1. Makes empty data `Data` 2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData. 2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column 3. Removes some validations that are no longer necessary * Removes `Experiment._default_data_type` * Removes `Experiment.default_data_type` * Removes `Experiment.default_data_constructor` **Some TODOs for follow-up diffs:** * Deprecate or remove `default_data_type` argument to experiment * Remove `Metric.data_constructor` (if needed, replacing it with a boolean attribute indicating whether a progression will be produced) * Convert some `Metric` methods such as `_unwrap_experiment_data` into static methods or move them off `Metric` entirely now that they do not reference the `data_constructor` attribute Reviewed By: lena-kashtelyan Differential Revision: D89689313
4f8c624 to
91f5d9f
Compare
…a_type (facebook#4691) Summary: **Context:** `default_data_constructor` and `default_data_type` are used for a few purposes: 1. Determining the type of empty data 2. Determining the type of data that results from combining multiple `Data`s 3. Validating that observations passed match the `default_data_type` on the experiment Now that we have reduced our data classes down to just `Data` and `MapData`, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data. This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column. **This PR:** 1. Makes empty data `Data` 2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData. 2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column 3. Removes some validations that are no longer necessary * Removes `Experiment._default_data_type` * Removes `Experiment.default_data_type` * Removes `Experiment.default_data_constructor` **Some TODOs for follow-up diffs:** * Deprecate or remove `default_data_type` argument to experiment * Remove `Metric.data_constructor` (if needed, replacing it with a boolean attribute indicating whether a progression will be produced) * Convert some `Metric` methods such as `_unwrap_experiment_data` into static methods or move them off `Metric` entirely now that they do not reference the `data_constructor` attribute Reviewed By: lena-kashtelyan Differential Revision: D89689313
91f5d9f to
48acdce
Compare
…a_type (facebook#4691) Summary: **Context:** `default_data_constructor` and `default_data_type` are used for a few purposes: 1. Determining the type of empty data 2. Determining the type of data that results from combining multiple `Data`s 3. Validating that observations passed match the `default_data_type` on the experiment Now that we have reduced our data classes down to just `Data` and `MapData`, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data. This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column. **This PR:** 1. Makes empty data `Data` 2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData. 2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column 3. Removes some validations that are no longer necessary * Removes `Experiment._default_data_type` * Removes `Experiment.default_data_type` * Removes `Experiment.default_data_constructor` **Some TODOs for follow-up diffs:** * Deprecate or remove `default_data_type` argument to experiment * Remove `Metric.data_constructor` (if needed, replacing it with a boolean attribute indicating whether a progression will be produced) * Convert some `Metric` methods such as `_unwrap_experiment_data` into static methods or move them off `Metric` entirely now that they do not reference the `data_constructor` attribute Reviewed By: lena-kashtelyan Differential Revision: D89689313
48acdce to
5eebbea
Compare
…a_type (facebook#4691) Summary: Pull Request resolved: facebook#4691 **Context:** `default_data_constructor` and `default_data_type` are used for a few purposes: 1. Determining the type of empty data 2. Determining the type of data that results from combining multiple `Data`s 3. Validating that observations passed match the `default_data_type` on the experiment Now that we have reduced our data classes down to just `Data` and `MapData`, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data. This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column. **This PR:** 1. Makes empty data `Data` 2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData. 2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column 3. Removes some validations that are no longer necessary * Removes `Experiment._default_data_type` * Removes `Experiment.default_data_type` * Removes `Experiment.default_data_constructor` **Some TODOs for follow-up diffs:** * Deprecate or remove `default_data_type` argument to experiment * Remove `Metric.data_constructor` (if needed, replacing it with a boolean attribute indicating whether a progression will be produced) * Convert some `Metric` methods such as `_unwrap_experiment_data` into static methods or move them off `Metric` entirely now that they do not reference the `data_constructor` attribute Differential Revision: D89689313 Privacy Context Container: L1307644 Reviewed By: lena-kashtelyan
|
This pull request has been merged in 385ee61. |
Summary:
Context:
default_data_constructoranddefault_data_typeare used for a few purposes:Datasdefault_data_typeon the experimentNow that we have reduced our data classes down to just
DataandMapData, and there is only one map key, and those two classes now differ mainly in whether they have a "step" column, there is little reason to worry so much about tracking the intended type of data.This PR brings us closer to unifying Data and MapData, because with this change, it should always be the case that a data is a MapData if and only if it has a "step" column; thus, there is no information contained in the class that can't be obtained by chacking whether there is a "step" column.
This PR:
Data2a. When combining multiple datas, the result is MapData if one of the constituent objects is a MapData.
2b. When making a Data from a DataFrame, it should be a MapData if there is a "step" column
TODO for this PR:
Experiment'sdefault_data_typeargumentSome TODOs for follow-up diffs:
default_data_typeargumentMetric.data_constructor(if needed, replacing it with a boolean attribute indicating whether a progression will be produced)Metricmethods such as_unwrap_experiment_datainto static methods or move them offMetricentirely now that they do not reference thedata_constructorattributeDifferential Revision: D89689313