Pour l'instant, étant donné que Woodwork finalise les plans de grandes mises à jour. Si Woodwork devient une extension des pandas, nous ne voudrons peut-être pas ou n'aurons pas besoin de le faire.

@angela97lin et moi nous sommes enregistrés et avons discuté de quelques options de mise en œuvre :

1. Demandez à l'évaluation du graphique des composants de transmettre des pandas à chaque composant. Pour indiquer les types ww aux composants, ajoutez de nouveaux champs à fit etc., ou respectez le modèle de featurizer de texte consistant à utiliser les paramètres init pour indiquer les colonnes pertinentes. Inconvénient : laid du point de vue de l'API, c'est pourquoi nous avons créé la menuiserie en premier lieu.
2. Lors de l'évaluation du graphique des composants, passez la menuiserie à chaque composant. Demandez à chaque composant de renvoyer des pandas. Inconvénient : une limitation potentielle est que les composants ne peuvent pas modifier le type de menuiserie des entités en entrée ou des entités nouvellement générées, sauf en modifiant le dtype pandas. Cependant, nous n'avons aucun composant qui en dépend.
3. Lors de l'évaluation du graphique des composants, passez la menuiserie à chaque composant. Demandez à chaque composant de retourner les boiseries. Défi : la plupart des composants doivent être convertis en pandas en interne pour effectuer des transformations telles que l'ajout de fonctionnalités, la suppression de fonctionnalités ou la modification de fonctionnalités. Après ces transformations, nous devons nous assurer que les types de menuiserie d'origine entrent dans la nouvelle table de données de menuiserie renvoyée, sinon les paramètres remplacés par l'utilisateur seront perdus, comme ils le sont aujourd'hui.

Statut : @angela97lin poursuit actuellement l'option 3 dans #1668

Plan : nous poursuivrons cette stratégie, en gardant un œil sur le temps d'exécution réduit en raison des multiples instanciations de la table de données ww. Et nous examinerons s'il y a des demandes de fonctionnalités que nous devrions faire à la menuiserie pour faciliter cela. Nous garderons également un œil sur toutes les options intéressantes que nous avons peut-être manquées jusqu'à présent.

@chukarsten @gsheni

Il semble que la troisième option soit la meilleure et la plus propre. Espérons que les performances ne soient pas affectées, mais conceptuellement, cela semble solide. Merci de l'avoir porté à mon attention... j'essaie de comprendre toutes ces choses.

Hacker dessus et réfléchir un peu plus:

L'objectif final est que nous ayons besoin d'un moyen de garder une trace des types logiques d'origine que l'utilisateur souhaite. Il peut s'agir d'informations détenues par le graphe de composants ou transmises à chaque composant responsable de la restauration de ces types après la transformation de certaines données. Poursuivez actuellement 3 et ajoutez les informations au graphique des composants car c'est le plus facile à tester (plutôt que de mettre à jour chaque composant) ... mais au niveau du composant, cela n'aurait aucun sens.

Supposons qu'un utilisateur spécifie un Woodwork DataTable et convertit explicitement un col catégorique en langage naturel. L'utilisateur passe cela à un composant. Nous devons convertir en pandas pour passer à des bibliothèques externes, et nous aimerions retourner un objet Woodwork. Si nous appelions simplement un constructeur Woodwork, il ne prendrait que le type inféré (catégoriel), ce qui est impair ? Nous devons donc garder une trace du type de langage naturel spécifié d'origine et le convertir avant de le rendre à l'utilisateur.

Il est intéressant de noter le scaler standard : il peut prendre des colonnes entières et les convertir en flottants. Si nous essayons ensuite de remettre le col au type d'origine (int), on nous criera dessus pour avoir essayé de convertir des flottants en int alors que ce n'est pas sûr. 😬

Mise à jour : j'ai eu une discussion rapide avec @dsherry et @chukarsten. J'implémente actuellement le n ° 3, mais le gestionnaire de graphique des composants garde une trace des types d'utilisateurs d'origine et met à jour ces informations au fur et à mesure qu'elles sont transmises d'un composant à l'autre. Cela fonctionne bien et nous amène à un endroit où AutoML / pipelines fonctionnent, mais après la fusion de # 1668, nous devrions nous attaquer à la gestion de cela au niveau du composant et supprimer ce code du graphique des composants.

Ma prochaine tâche à faire : corriger les tests d'index de la mise à jour de la branche à partir de la branche principale, nettoyer les commentaires et les problèmes de fichiers qui peuvent être résolus sans rapport avec ce PR (juste le code de nettoyage général). Une fois que le code est plus propre, recherchez les redondances et le profil pour voir d'où vient cette énorme différence de temps / ce que nous pouvons faire à ce sujet.