alteryx / alteryx/evalml

Change `_schema_is_equal` to allow nullable and non nullable types to be used interchangably between train and test data

Aperta
#4,077 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub
Lingua principale
Python
Stelle
850
Fork
96
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Descrizione

As a user, I wish I could train a pipeline on data that might not have nans and has non nullable types and then predict/`transform_all_but_final` /score data that has nans and therefore has nullable types.

Currently, having nullable types at train and non nullable types at test (or visa versa) causes `ComponentGraph._transform_features` to error with `Input X data types are different from the input types the pipeline was fitted on`, but other than whether or not they may contain null values, nullable types and their non nullable counterparts contain the same type of data.

Once the nullability epic is in place, we may see increased usage of nullable types, which could result in more instances of the above situation popping up.

I propose we change `_schema_is_equal` to treat the following nullable types interchangably with their non nullable counterparts
- `Integer` - `IntegerNullable`
- `Boolean` - `BooleanNullable`
- `Age` - `AgeNullable`

There are several things to take into account when implementing this:
- Overall, think about the impact of allowing these types to be used interchangably
- Consider requiring that we validate the existence of NaNs before treating nullable and non nullable types as equivalent - In general, I don't want us to shy away from keeping IntegerNullable columns as such even if no nans are present (whether we impute them ourselves or users input them). Those types aren't really meant to imply the presence of nans, just that the type can support null values, but other than that they're the same as non nullable integers. For example, in Featuretools, we might output types as IntegerNullable from a Primitive so that users could pass nans in and not have it break.
- Increase test coverage of the different ways data could be different between train and test data for the different problem types and the `score`, `predict`, and `transform_all_but_final` methods on pipelines
- Confirm this doesn't change automl results before or after nullable type handling changes

Guida per i contributori

Apri la guida per i contributori

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.