Evalml: Autoriser les composants qui ne sont pas des enfants « feuilles » dans la hiérarchie des classes

Créé le 23 mars 2021  ·  4Commentaires  ·  Source: alteryx/evalml

En travaillant sur #1989, @freddyaboulton a suggéré que nous fassions de TargetImputer une sous-classe de SimpleImputer . Malheureusement, lors de la recherche de composants viables dans _get_subclasses , _get_subclasses ne collectera que les classes qui se trouvent tout en bas de la hiérarchie. Par example:

ComponentBase --> Transformer --> SimpleImputer # will only grab SimpleImputer

Le problème est que si nous sous-classons SimpleImputer, nous aurons accès à TargetImputer, mais SimpleImputer ne sera plus trouvé par EvalML en tant que composant utilisable :

ComponentBase --> Transformer --> SimpleImputer --> TargetImputer 
# will only grab TargetImputer, SimpleImputer is no longer a leaf

Je crois que l'intention d'origine est de ne pas récupérer les classes qui ne sont pas utiles (ex: Transformer), mais c'est un problème si nous voulons nous appuyer sur des composants utiles pour en créer de nouveaux.

Commentaire original ici : https://github.com/alteryx/evalml/pull/1989#discussion_r599894996

bug

Tous les 4 commentaires

Options :
1.) Demandez au TargetImputer d'utiliser le SimpleImputer.
2.) Ne définissez pas le composant TargetImputer, mais appliquez plutôt le SimpleImputer à la cible.
3.) Supprimez _get_subclasses() en faveur d'une liste statique de composants. (préféré)
4.) Rendre _get_subclasses() plus intelligent.

Prochaine étape : planifier une discussion pour décider comment procéder.

Mon opinion est que nous ne devrions rien changer à moins que nous ne voulions faire de l'héritage des classes non de base un modèle plus courant dans notre base de code. Nous ne le faisons pas actuellement, donc construire un système pour permettre cela me semble une faible priorité.

Ce problème ne bloque pas l'imputeur cible ou tout travail à court terme que nous avons devant nous et le système actuel d'identification des sous-classes « œuvres ». Si nous voulons vraiment 3 alors c'est une autre histoire hehe et je serais prêt à entendre des arguments pour cela, mais je ne pense pas qu'il soit nécessaire de le faire.

Et si nous voulions tirer parti du SimpleImputer dans le TargetImputer à l'avenir, nous pouvons utiliser la composition plutôt que l'héritage, ce à quoi je pense que l'option 1 fait référence.

D'accord avec @freddyaboulton ici, il convient également de noter que nous avons défini _get_subclasses() en premier lieu, car le suivi d'une liste statique de composants était un peu fastidieux / frustrant car nous ajoutions de plus en plus de composants. Si nous optons pour 3, il serait peut-être plus logique de conserver _get_subclasses() mais également de conserver une liste d'"exceptions" telles que le cas SimpleImputer / TargetImputer, afin qu'elles soient incluses, mais d'autres composants tels que le Transformer sont toujours exclus.

Aussi d'accord avec l'idée d'une technique de composition si cela fait le travail.

@angela97lin Pensez-vous que nous pouvons fermer cela? Je pense que nous convenons que nous n'avons pas besoin d'apporter des modifications à _get_subclasses pour permettre le développement de TargetImputer/d'autres composants.

Cette page vous a été utile?
0 / 5 - 0 notes