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
Mostly for discussion, but it seems like trying to use anything aside from entity_id when specifying groups in a feature aggregation (e.g., zipcode, etc) is currently pretty error-prone. For instance, if there isn't a 1-to-1 relationship between the entity_id and these other columns, you'll end up with multiple records in the matrix with the same (entity_id, as_of_date) key, which causes many problems downstream.
Thoughts on how to improve the functionality here? Some options:
Remove groups from the experiment config and always assume only entity_id?
Allow the user to specify non-entity_id groups, but make them somehow override a validation check to make it clear this is "advanced" functionality?
Check that matrices have no duplicate entity_id/as_of_date pairs and raise an early error if they do?
Other ideas?
The text was updated successfully, but these errors were encountered:
Note that we decided to remove support for collate groups other than entity_id for the time being via #887, especially pending further discussion on what direction we want to go with feature engineering generally in the future. Will go ahead and close this issue for now, though it's possible someone might want to revisit this question in the future.
Mostly for discussion, but it seems like trying to use anything aside from
entity_id
when specifyinggroups
in a feature aggregation (e.g., zipcode, etc) is currently pretty error-prone. For instance, if there isn't a 1-to-1 relationship between the entity_id and these other columns, you'll end up with multiple records in the matrix with the same(entity_id, as_of_date)
key, which causes many problems downstream.Thoughts on how to improve the functionality here? Some options:
groups
from the experiment config and always assume onlyentity_id
?entity_id
groups, but make them somehow override a validation check to make it clear this is "advanced" functionality?The text was updated successfully, but these errors were encountered: