Remove Data.from_multiple and MapData.from_multiple #4714
+151
−353
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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
Summary: Or we could just remove it, since it's non-API... Differential Revision: D89744225
Summary: **Context**: When multiple datas are combined into one, the resulting type should be determined by the inputs, so there should be no need for a user to decide between calling `Data.from_multiple_data` and `MapData.from_multiple_data` (the former will error if MapData is provided, while the latter will always produce MapData) **Changes**: * Removes `Data.from_multiple` and `MapData.from_multiple` * Replaces references to those with `combine_datas_infer_type`. Note that that function makes empty data `MapData` so that `MapMetric`s continue to return `MapData`. Differential Revision: D89745117
meta-cla
bot
added
the
CLA Signed
|
@esantorella has exported this pull request. If you are a Meta employee, you can view the originating Diff in D89745117. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
Context:
When multiple datas are combined into one, the resulting type should be determined by the inputs, so there should be no need for a user to decide between calling
Data.from_multiple_dataandMapData.from_multiple_data(the former will error if MapData is provided, while the latter will always produce MapData)Changes:
Data.from_multipleandMapData.from_multiplecombine_datas_infer_type. Note that that function makes empty dataMapDataso thatMapMetrics continue to returnMapData.Differential Revision: D89745117