Dies vorerst, angesichts der Tatsache, dass Woodwork Pläne für große Updates fertigstellt. Wenn Woodwork zu einer Erweiterung von Pandas wird, wollen oder müssen wir dies möglicherweise nicht tun.

@angela97lin und ich haben eingecheckt und einige Implementierungsoptionen besprochen:

1. Lassen Sie die Auswertung von Komponentendiagrammen Pandas an jede Komponente übergeben. Um Komponenten ww-Typen anzuzeigen, fügen Sie entweder neue Felder zu fit usw. hinzu oder bleiben Sie beim Textfeaturizer-Muster, bei dem Init-Parameter verwendet werden, um relevante Spalten anzugeben. Nachteil: Aus API-Sicht hässlich, deshalb haben wir überhaupt Holzarbeiten erstellt.
2. Übergeben Sie während der Auswertung des Komponentendiagramms Holzarbeiten an jede Komponente. Lassen Sie jede Komponente Pandas zurückgeben. Nachteil: Eine potenzielle Einschränkung besteht darin, dass Komponenten den Holzwerktyp der Eingabe-Features oder neu generierter Features nicht ändern können, außer durch Ändern des Pandas-Dtypes. Wir haben jedoch keine Komponenten, die darauf angewiesen sind.
3. Übergeben Sie während der Auswertung des Komponentendiagramms Holzarbeiten an jede Komponente. Lassen Sie jede Komponente Holzarbeiten zurückgeben. Herausforderung: Die meisten Komponenten müssen intern in Pandas konvertiert werden, um Transformationen wie das Hinzufügen von Features, das Löschen von Features oder das Ändern von Features durchzuführen. Nach diesen Transformationen müssen wir sicherstellen, dass die ursprünglichen Holzwerktypen in die neue zurückgegebene Holzwerkdatentabelle gelangen, da sonst vom Benutzer überschriebene Einstellungen wie heute verloren gehen.

Status: @angela97lin verfolgt derzeit Option 3 in #1668

Plan: Wir werden diese Strategie fortsetzen und dabei auf reduzierte Laufzeiten aufgrund mehrerer Instanziierungen von ww-Datentabellen achten. Und wir werden prüfen, ob es irgendwelche Feature-Anfragen gibt, die wir an die Holzarbeiten richten sollten, um dies zu vereinfachen. Wir werden auch nach überzeugenden Optionen Ausschau halten, die wir bisher möglicherweise übersehen haben.

@chukarsten @gsheni

Es scheint, als wäre die dritte Option die beste und sauberste Option. Hoffentlich wird die Leistung nicht beeinträchtigt, aber konzeptionell scheint es solide zu sein. Danke, dass Sie mich darauf aufmerksam gemacht haben ... ich versuche, mich um all die Dinge zu kümmern.

Darauf hacken und noch etwas nachdenken:

Das Endziel ist, dass wir eine Möglichkeit brauchen, die ursprünglichen logischen Typen zu verfolgen, die der Benutzer wünscht. Dies können Informationen sein, die im Komponentengraphen gespeichert sind, oder an jede Komponente weitergegeben werden, die dafür verantwortlich ist, diese Typen nach dem Transformieren einiger Daten zurückzusetzen. Derzeit verfolge ich 3 und füge die Informationen dem Komponentendiagramm hinzu, da dies am einfachsten zu testen ist (anstatt jede Komponente zu aktualisieren) ... aber auf Komponentenebene würde es keinen Sinn machen.

Angenommen, ein Benutzer gibt eine Woodwork DataTable an und konvertiert explizit eine kategoriale Spalte in natürliche Sprache. Der Benutzer übergibt das an eine Komponente. Wir müssen in Pandas konvertieren, um es an externe Bibliotheken weiterzugeben, und wir möchten ein Woodwork-Objekt zurückgeben. Wenn wir einfach einen Woodwork-Konstruktor aufrufen, würde er nur den abgeleiteten Typ (kategorisch) annehmen, was seltsam ist? Daher sollten wir den ursprünglich angegebenen natürlichen Sprachtyp verfolgen und konvertieren, bevor wir ihn an den Benutzer zurückgeben.

Interessant ist der Standard-Scaler: Er könnte int-Spalten nehmen und sie in Floats umwandeln. Wenn wir dann versuchen, col auf den ursprünglichen Typ (int) zurückzusetzen, werden wir angeschrien, weil wir versucht haben, floats in int umzuwandeln, wenn das nicht sicher ist. 😬

Update: hatte eine kurze Diskussion mit @dsherry und @chukarsten. Ich implementiere derzeit Nr. 3, habe aber das Komponentendiagramm, um die ursprünglichen Benutzertypen zu verfolgen und diese Informationen zu aktualisieren, wenn sie von Komponente zu Komponente weitergegeben werden. Das funktioniert gut und bringt uns an einen Punkt, an dem AutoML / Pipelines funktionieren, aber nachdem #1668 zusammengeführt wurde, sollten wir uns damit befassen, dies auf Komponentenebene zu handhaben und diesen Code aus dem Komponentendiagramm zu entfernen.

Meine nächsten To-Dos: Index-Tests vom Update-Zweig vom Hauptverzeichnis aus beheben, Kommentare und Dateiprobleme bereinigen, die nicht mit diesem PR in Zusammenhang stehen (nur allgemeiner Bereinigungscode). Sobald der Code sauberer ist, suchen Sie nach Redundanzen und Profilen, um zu sehen, woher dieser enorme Zeitunterschied kommt / was wir dagegen tun können.