Woodworkが大規模な更新の計画を最終決定していることを考えると、今のところこれをパントします。 木工がパンダの延長になる場合、私たちはこれをしたくない、またはする必要がないかもしれません。

@ angela97linと私はチェックインし、いくつかの実装オプションについて話し合いました。

1. コンポーネントグラフの評価で、パンダを各コンポーネントに渡します。 コンポーネントにwwタイプを示すには、 fitなどに新しいフィールドを追加するか、initパラメーターを使用して関連する列を示すテキスト機能化パターンを使用します。 短所：APIの観点からは醜いので、そもそも木工を作成したのはこのためです。
2. コンポーネントグラフの評価中に、各コンポーネントに木工品を渡します。 各コンポーネントにパンダを返してもらいます。 短所：潜在的な制限は、パンダのdtypeを変更する場合を除いて、コンポーネントが入力フィーチャまたは新しく生成されたフィーチャの木工タイプを変更できないことです。 ただし、これに依存するコンポーネントはありません。
3. コンポーネントグラフの評価中に、各コンポーネントに木工品を渡します。 各コンポーネントに木工品を返却してもらいます。 課題：ほとんどのコンポーネントは、機能の追加、機能の削除、機能の変更などの変換を行うために、内部でパンダに変換する必要があります。 これらの変換後、元の木工タイプが新しく返された木工データテーブルに含まれることを確認する必要があります。そうしないと、現在のように、ユーザーが上書きした設定が失われます。

ステータス： @ angela97linは現在＃1668のオプション3を追求しています

計画：複数のwwデータテーブルのインスタンス化による実行時間の短縮に注意しながら、その戦略を継続します。 そして、これを簡単にするために木工に行うべき機能要求があるかどうかを検討します。 また、これまで見逃していた可能性のある魅力的なオプションにも注意を払います。

@chukarsten @gsheni

3番目のオプションが最良で最もクリーンなオプションのようです。 パフォーマンスに影響がないことを願っていますが、概念的には健全なようです。 私の注意を引いてくれてありがとう...すべてのものに頭を包み込もうとしています。

これをハッキングして、もう少し考えてみましょう。

最終的な目標は、ユーザーが必要とする元の論理型を追跡するための何らかの方法が必要になることです。 これは、コンポーネントグラフによって保持されている情報であるか、データを変換した後にそれらのタイプを元に戻す責任がある各コンポーネントに渡される可能性があります。 現在3を追求しており、（すべてのコンポーネントを更新するよりも）テストするのが最も簡単なため、コンポーネントグラフに情報を追加しています...しかし、コンポーネントレベルでは、意味がありません。

ユーザーがWoodworkDataTableを指定し、カテゴリ列を自然言語に明示的に変換するとします。 ユーザーはそれをコンポーネントに渡します。 外部ライブラリに渡すためにパンダに変換する必要があり、Woodworkオブジェクトを返したいと思います。 単にWoodworkコンストラクターを呼び出すと、推測された型（カテゴリ）のみが使用されますが、これは奇妙なことですか？ したがって、ユーザーに返す前に、元の指定された自然言語タイプを追跡し、変換する必要があります。

注目すべき興味深いのは、標準のスケーラーです。int列を取り、それらをfloatに変換できます。 次に、colを元の型（int）に戻そうとすると、安全でないときにfloatをintに変換しようとすると怒鳴られます。 😬

更新： @dsherryおよび@chukarstenと簡単に話し合いました。 私は現在＃3を実装していますが、コンポーネントグラフに元のユーザータイプを追跡し、コンポーネントからコンポーネントに渡されるときにその情報を更新するようにしています。 これは問題なく機能し、AutoML /パイプラインが機能する場所に到達しますが、＃1668がマージされた後、コンポーネントレベルでこれを処理し、コンポーネントグラフからこのコードを削除することに取り組む必要があります。

私の次のやること：メインからブランチを更新することによるインデックステストを修正し、このPRに関係なく対処できるコメントとファイルの問題をクリーンアップします（一般的なクリーンアップコードのみ）。 コードがよりクリーンになったら、冗長性とプロファイルを探して、この大きな時間差がどこから来ているのか、それに対して何ができるのかを確認します。