Scikit-learn: CategoricalEncoder APIを再考しますか？

要約@jorisvandenbosscheをありがとう。 私はオプション2に賛成だと思います： OneHotEncoderクラスを再利用し、奇妙な属性を廃止し、コンストラクターパラメーターを追加して、デフォルトの動作が変更されるが沈黙を容易にするという将来の警告とともに動作を選択しますそのオプションの値を渡すだけでその警告が表示されます。

CategoricalEncoderを元に戻すというアイデアは私をかなり悲しくさせますが、私は思います
あなたは、将来のユーザーがオプション2によってあまり神秘化されないだろうということは正しいです。私のメイン
懸念されるのは、これをOHEの変更として実装しようとしたことです。
長い間、それは決して飛ばなかった。 おそらく、
提案されたものに従ったOneHotEncoderdocstringへの変更
変更するので、正常に見えるかどうかを確認できます。

ジョエルが言ったことに+1

⁣私の電話から送信されました。 タイプミスや簡潔さはご容赦ください。

午前12時28分に2018年1月23日、12：28、で、ジョエルNothmanの[email protected]は書きました：

CategoricalEncoderを元に戻すというアイデアは私を非常に悲しくさせますが、私は
考える
あなたは正しいです、将来のユーザーはオプション2によってそれほど神秘的ではないでしょう。
主要
懸念されるのは、これをOHEの変更として実装しようとしたことです。
NS
長い間、それは決して飛ばなかった。 おそらく、
提案されたものに従ったOneHotEncoderdocstringへの変更
変更するので、正常に見えるかどうかを確認できます。

-
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment -359761818

CategoricalEncoderを元に戻すというアイデアは、私を非常に悲しくさせます

明確にするために、それは元に戻すことではなく、すべての機能を保持するリファクタリング/名前変更になります！
しかし、私は「CategoricalEncoder」という名前も好きです。それは本当に悲しいことです。

そうは言っても、私はすぐに変更を加えて、これをOnehotEncoderに統合することがどれほど可能かを考えます。

OK、概念実証付きのPRを開きました： https ：
まだ完了していません（非推奨の警告や新しい属性は、古い動作ではまだ計算されていません）。

APIの主な質問は、入力データの形式に関するものです。
要約すると、現在、カテゴリデータを処理する方法はます。

1）実際の、まだエンコードされていない（整数または文字列）カテゴリデータ（ CategoricalEncoderでどのように行われるか）->トレーニングデータの一意の値からカテゴリを推測します
2）整数として、すでにエンコードされたデータ（現在のOneHotEncoderどのように行われるか）->トレーニングデータの最大値からカテゴリを推測します

問題は、両方のケースをサポートする価値があると思いますか？ したがって、マージされる可能性のあるOneHotEncoderでは、両方を実行する機能を維持しますか、それとも完全に非推奨にしてから、序数入力を処理する機能を削除しますか？

両方を処理する機能が必要な場合は、ブールキーワードを追加して入力データ型を指定できます（今のところencoded_input=False/Trueを使用していますが、他のアイデアはordinal_inputです...）

非推奨期間については、とにかく両方をサポートする必要があります。また、動作を選択するためのキーワードを導入する必要があります（警告を消して新しい動作を選択できるようにするため）。
したがって、原則として、後でキーワードを保持することができます。

両方を処理したい場合、OneHotEncoderの動作の概要は次のとおりです。

• 今のところencoded_input=Noneであり、データに基づいてデフォルトを推測します
• intのようなデータ（以前はOneHotEncoderによって処理されていた）の場合、 encoded_inputは内部的にTrueに設定され、非推奨の警告が発生します。 ユーザーが現在の動作を維持したい場合は、手動でOneHotEncoder(encoded_input=True)として指定して、警告を消すことができます。
• 入力がintに似ていない場合は、 encoded_input内部的にFalseに設定し、警告なしに新しい動作（=現在のCategoricalEncoderの動作）を使用します。
• 将来的には、デフォルトのencoded_inputをNoneからFalseに変更します（デフォルトでは、intのようなデータの場合も新しい動作です）

最大値からカテゴリを推測することによる実際的な違いが、あなたが何を示唆しているのかはまだわかりません。

@jnothman実際には違いがあることを認めていると思いますか？ （あなたが持っているデータに応じてあなたが得る出力）

しかし、この違いが実際に重要かどうかはわかりません。 そこでフィードバックをお願いします。 誰かが実際にこの「最大値」ベースの方法を望んでいるかどうか、または（将来的には非推奨になった後）「一意の値」ベースの方法だけで問題がないかどうか。

私は個人的にこの最大値ベースのメソッドを必要としないと思いますが、OneHotEncoderは長年そのようなものでした（正当な理由があるかどうか？）。

実際に最大値ベースの分類を非推奨にすると、（非推奨後の）実装が確実に簡単になります。
そして、そのルートを選択した場合、オプションはencoded_input / ordinal_inputではなくlegacy_mode=True/Falseであることに同意します

n_values = 'auto'の場合、出力の実際の違いを思い出してください。
お願いします？ 私はactive_features_のものが基本的にそれらを作ったと思っていました
同じですが、私はおそらく何かを忘れています。

ああ、それは私たちの誤解を明らかにします:-)
現在のOneHotEncoderが実際にどのように機能しているかを誤解しました。 値が[2、3、5、2]のフィーチャが1つあるとします。 現在のOneHotEncoderにはカテゴリ[0、1、2、3、4、5]があると思いました（現在のCategoricalEncoderにはカテゴリ[2、3、5]があります）。 ただし、 active_features_も[2、3、5]のみであり、基本的にデフォルト値のn_values='auto'と同じになります。

したがって、整数をn_values渡して（上記の場合のcategories = [0、1、2、3、4、5]のn_values=6のように）、実際にAPIの変更となるカテゴリの数（非推奨/削除）。
そして、それはユーザーがcategories=range(6)で簡単に置き換えることができます

混乱させて申し訳ありません。
その観点から、 legacy_modeオプションも必要ないと思います。 n_values=6をcategories=range(6)内部的に変換し、警告を発することができます（ただし、実際のテストでこれを確認する必要があります）。

他の違いは、見えないカテゴリの処理です。 OneHotEncoderの現在の動作では、表示されない値が範囲（0、max）内にある場合、 handle_unknow='error' （デフォルト）であってもエラーは発生しません。 しかし、そのような場合、ユーザーが既存の動作を維持するために手動でhandle_unknown='ignore'を設定する必要があるという警告を出すことによって、それを個別に解決することもできます。

失う唯一の機能は、range（0、max）内にある不明なカテゴリ（現在のOneHotEncoderでは「不明」とは見なされない）とそれより大きいカテゴリ（> max、現在すでに見なされているカテゴリ）の違いです。 OneHotEncoderでは不明）。

いいえ、それは私たちが以前に試したようなものであり、それも
気難しい。 現在の行動を維持する正当な理由がない限り、私たちは
ゆっくりと未来へと導くために、legacy_modeが必要です。

いいえ、それは私たちが以前に試したようなものであり、あまりにも気難しいものです。

この「いいえ」がどの側面を指しているのか明確にできますか？
legacy_modeは必要ないと思うのですが？

はい、両方とも逆になっているものを作ることができるという考えに
互換性があり、今後何が欲しいか

はい、下位互換性と今後の目標の両方を実現できるものを作成できるという考えに

それは私が提案しようとしたことではありませんでした。 legacy_modeキーワードを持たないことは、魔法のように後方互換性と将来の必要性の両方を持たせることによってではなく、既存のキーワードの動作を非推奨にすることによって可能であると考えることを明確にしたかったのです。

具体的には、デフォルト以外の値であるn_valuesは非推奨になる可能性があり、 categories仕様に置き換える必要があります。 整数データの場合のhandle_unknowは、現在のミックスの代わりに完全無視または完全エラーのいずれかを選択するようにユーザーが明示的に設定する必要があります（そうしないと、非推奨の警告が発生します）。

したがって、.fit（[[5]]）。transform（[[4]]）を実行すると、n_valuesの値は
カテゴリとhandle_umknownはエラーを引き起こしますか？

2018年1月25日午前9時32分、「Joris VandenBossche」 [email protected]
書きました：

はい、両方とも逆になっているものを作ることができるという考えに
互換性があり、今後何が欲しいか

それは私が提案しようとしたことではありませんでした。 私はそれを考えることを明確にしたかった
魔法のように持っているのではなく、legacy_modeキーワードを持たない可能性があります
後方互換性と将来必要なものの両方ですが、非推奨にすることによって
既存のキーワードの動作。

具体的には、デフォルト以外の値のn_valuesは非推奨になり、
カテゴリ仕様に置き換える必要があります。 の場合はhandle_unknow
整数データは、完全ないずれかを選択するためにユーザーが明示的に設定する必要があります
現在のミックスの代わりに無視または完全なエラー（およびその他の場合は非推奨）
警告が発生します）。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment-360296569 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAEz6-DrQWep22_gs-hg9cC0u19B1_PSks5tN6-HgaJpZM4RpUE8
。

非推奨の際にカテゴリを設定する必要があるようにすることはできますか
明示的に、そして警告付きのレガシーモードは他の方法で有効ですか？ それですか
あなたが提案していることは何ですか？

非推奨の際にカテゴリを明示的に設定する必要があり、それ以外の場合は警告付きのレガシーモードが有効になるようにすることはできますか？ それはあなたが提案していることですか？

はい、まだケースが欠落している可能性がありますが、これは可能だと思います（来週実際にコーディングして確認します）。

さまざまな「レガシー」ケース：

• n_values = 'auto'（デフォルト）
  
  
  
  • handle_unknown = 'ignore'->正常、動作に変更はありません
  
  
  • handle_unknown = 'error'->問題、範囲内の値は引き続き無視され、範囲エラーを超える値
    
    
    
    
    
    • 考えられる解決策：
      
      
      
      
      
      
      
      • 適合している場合、範囲が連続している場合=>問題なく、動作に変化はありません（LabelEncoderを組み合わせたすべての人にとって、これは私が思う典型的なユースケースです）
      
      
      
      
      • そうでない場合：この動作を維持するために（そして内部的にレガシーモードを使用するために）カテゴリを明示的に設定する必要があることを非推奨の警告を発します
      
      
      
      
    
    
    
  
  
• n_values = value
  
  
  
  • これは内部的にcategories = [range（value）]に変換でき、ユーザーが将来それを行う必要があるという非推奨の警告を発します
  
  
  • この場合、 handle_unknown='error' / 'ignore'は期待どおりに機能します
  
  

n_values='auto'場合の非推奨の警告は、 fitでのみ発生し、構築時には発生しません（これは実際には理想的ではありません）が、ユーザーがそれを渡していることがわかっている場合にのみ適切です。文字列データではなく数値データ。

通常、どのような場合でも適合するまで警告を発することはないので、心配する必要はありません。
それ。

その戦略はほとんど良いように聞こえます。

データ内の文字列をスニッフィングする必要があるかどうかは実際にはわかりませんが、
けれど。 基本的には次のようにします。カテゴリが次の場合、レガシーモードがアクティブになります
データはすべての整数の場合は設定していませんか？

1つの質問：categoriesとn_valuesパラメーターがデフォルトの場合は、
カテゴリを公開します_？ n_valuesが明示的に設定されている場合、公開しますか
カテゴリ_？

2018年1月29日午前10時、「Joris VandenBossche」 [email protected]
書きました：

非推奨の際にカテゴリを設定する必要があるようにすることはできますか
明示的に、そして警告付きのレガシーモードは他の方法で有効ですか？ それですか
あなたが提案していることは何ですか？

はい、まだケースが欠落している可能性がありますが、これは可能だと思います（
来週実際にコーディングして確認してください）。

さまざまな「レガシー」ケース：

• n_values = 'auto'（デフォルト）
  
  
  
  • handle_unknown = 'ignore'->正常、動作に変更はありません
  
  
  • handle_unknown = 'error'->問題、範囲内の値はまだ
    
    無視され、範囲エラーを超える値
    
    
    
    
    
    • 考えられる解決策：
      
      
      
      
      
      
      
      • 適合、範囲が連続している場合=>細かい、変化なし
        
        
        
        動作（LabelEncoderとこれを組み合わせたすべての人にとって、
        
        
        
        私が思う典型的なユースケース）
      
      
      
      
      • そうでない場合：非推奨の警告を発します
        
        
        
        この動作を維持するには、カテゴリを明示的に設定する必要があります（および
        
        
        
        内部的にレガシーモードを使用）
      
      
      
      
    
    
    
    • n_values = value
    
    
    
  
  
  • これは、内部的にcategories = [range（value）]に変換できます。
    
    そして、ユーザーが自分でそれを行うべきであるという非推奨の警告を発します
    
    将来
  
  
  • この場合、handle_unknown = 'error' / 'ignore'は期待どおりに機能します
  
  

n_values = 'auto'の場合の非推奨の警告は、
フィットし、建設時ではありません（これは本当に理想的ではありません）が、それは
ユーザーが文字列ではなく数値データを渡していることがわかっているので、
データ。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment-361104495 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAEz6x8xnyZXBLij-DCC45JyYNf8pA5kks5tPPwXgaJpZM4RpUE8
。

あなたは基本的にはそれになりたい：レガシーモードは、データがすべての整数である場合のカテゴリーが設定されていない場合、アクティブであると？

はい、確かに（実際には多かれ少なかれ同じになります）

1つの質問：categoriesとn_valuesパラメーターがデフォルトの場合、categories_を公開しますか？ n_valuesが明示的に設定されている場合、categories_を公開しますか？

個人的には、レガシーモードであっても、新しいインターフェイスの属性を可能な限り提供します。 したがって、どちらの場合も、 categories_を計算します（少し手間がかかる場合でも）

だから私は上記のロジックをコードに入れようとしました（PRにいくつかの更新をプッシュします）、そしてn_valuesまたはcategoriesが設定されていない場合の整数データの場合についてもう1つの質問があります（ 'legacy_mode'の典型的なケース）。 問題は、推測されたカテゴリが単純に連続した範囲（0、1、2、3、... max）である場合、新しい動作と古い（レガシー）動作の間に違いがなく、違いがないという事実にあります。必然的に非推奨の警告を出す必要があります。
この特定の場合に行ういくつかの可能性：

1）このケースを検出し（推測されたカテゴリが連続した範囲であること）、その場合は警告を発しません。
-とにかくすでに適合しているので、これは（少し余分なコードの複雑さで）検出することが可能です
-私は、整数データをOneHotEncoder使用している場合、これは一般的なケースになると思うし、それは警告で彼/彼女を気にしないといいだろうように、ユーザーが実際に、私たちのリファクタリングを心配する必要はありません場合
2）常に警告を発し、そのような場合の対処方法を警告メッセージに示します（連続した範囲がない場合の対処方法の説明に加えて）。
-カテゴリとして連続した範囲しかないことがわかっている場合は、警告を無視したいので、これを行う方法の説明を警告メッセージに追加できます（コピーして貼り付けることができるfilterwarningsを含むコードサンプルを追加します）
-これの潜在的な利点は、LabelEncoderを使用して整数を作成した場合、OneHotEncoderを直接使用できるようになるという警告メッセージを追加できることです（これは現在、一般的な使用パターンだと思います）。 そうすれば、警告も消えます
3）常に警告を発しますが、それを黙らせるためのキーワードを提供します（例： legacy_mode=False ）
- filterwarningsステートメント（上記のポイント2を参照）を使用するアドバイスが面倒だとわかった場合は、キーワードを追加して同じ結果を得ることができます。
-これのデメリットは、非推奨がクリーンアップされたときに、いくつかのリリースで不要になったキーワードを導入することです。

私は個人的にオプション1または2を支持しています。OneHotEncoderの前にLabelEncoderを使用することは（クイックgithub検索からの）典型的なパターンのようです。そのような場合、常に連続した範囲があり、新しい実装なので、警告するべきではありません。 一方、警告が表示されれば、LabelEncoderを使用して
問題は、前の手順でLabelEncoderを使用していなくても、ユーザーがカテゴリなどの連続した整数を使用する頻度です。

うーん、私が忘れていた1つのケースは、連続していない整数の推定カテゴリがあるが（たとえば、[1,3,5]）、レガシー動作ではなく新しい動作が必要な場合です（その場合、警告を無視することはできません） 、変換ステップで見えない値を異なる方法で処理するため、つまり、範囲（2など）の間にある値はエラーを発生させません）。
legacy_mode=Falseキーワードを指定しない場合、新しい動作を取得する唯一の方法は、手動でcategories=[1,3,5]を渡すことです。これは、少し不便な場合があります。 それがオプション3を支持し、一時的なキーワードlegacy_mode=False導入に対する私の異議をあきらめる理由かもしれません（ただし、そのようなキーワードが実際に存在する唯一のケース*であるため、それが価値があるかどうかも完全にはわかりません必要）

*この唯一のケース=連続した範囲ではない推定カテゴリを持つ整数データであり、カテゴリを手動で設定できない/したくない、またはhandle_unknownを無視するように設定する場合。

すべての長いテキストで申し訳ありませんが、それは非常に複雑です:)

n_valuesが設定されていない場合についてのみ話しているのですよね？

私は1で大丈夫です、そしてそれは自動なのでそれ以上高価ではないでしょう
すでにラベルのセットを調べる必要があります。 私も受け入れることができました
シンプルさ、3の変形。これは「レガシーで実行されているOneHotEncoder」でした。
モード。 を使用せずにわずかに異なる動作を行うには、categories = 'auto'を設定します
警告。"

n_valuesが設定されていない場合についてのみ話しているのですよね？

はい（他のケースは、同等のcategories値に簡単に変換でき、非推奨の警告が表示され、新しい動作とレガシーの動作に違いはありません）

3.のバリアント。これは「OneHotEncoderがレガシーモードで実行されています。警告なしでわずかに異なる動作を行うには、categories = 'auto'を設定してください。」

ああ、それはいい考えのように聞こえます！ （連続したカテゴリのケースを検出するかどうかに関係なく）。 したがって、コードでデフォルトのcategoriesをNoneに設定し（デフォルトのセマンティクスを変更せずに）、ユーザーが明示的に設定したかどうかがわかります。そのようにして、 legacy_mode=Falseを示すのに適した方法です。その余分なキーワードを必要とせずに

はい、ただし、誰かがパスせずに使用するたびに警告したい場合に限ります
カテゴリ。 これは安価な実装アプローチですが、
ユーザーにとって不必要に冗長であるため、1を選択したいのです。
簡単に行うことができます。

これは何の新鮮な地獄ですか：-/

または、新しい名前をDummyEncoder ;）にすることもできます（ただし、DummyClassifierとは少し矛盾します）

@amueller上記のすべてを読まないでください！
私はちょうどこの問題の新しい読者のために素晴らしい要約を作ることを計画していました。 上記の説明は非常に複雑です（OneHotEncoderの現在の複雑な動作をまだ完全に理解していなかったためです... :-)）

または、新しい名前をDummyEncoderにすることもできます;）

@GaelVaroquauxはこれに反対したと思います。

命名の一貫性のためにこれをやり直すことは、私見の価値がありません。 私たちはどこでも名前を付けることに一貫性がありません。 これにつながる議論を要約していただけますか？

「ダミー」は統計家が使用するものであり、パンダが使用するものだと思います。

一番上の投稿はまだ正確で読む価値があり、CategoricalEncoderを保持しない理由を要約しています（これは、DummyEncoderの代わりにOneHotEncoderを使用する必要があるという意味ではありません。これは別の質問です）

一番上の投稿を読みました。 「一貫性を保つためにこれをやり直すことは価値がない」と私が言ったとき、それは私が言及したことです。

開かれている問題

それを説明できますか？

「一貫性のためにこれをやり直すことは価値がありません」

一貫して、「何を受け入れるか」と「何をするか」の命名スキームを指していますか？ もしそうなら、それはほんの小さな理由でした。 私にとって、それは主に、単一のクラスに機能を追加する際のスケーラビリティの問題です。

開かれている問題

欠落している値を処理する方法に関する問題があり（https://github.com/scikit-learn/scikit-learn/issues/10465）、このために、順序エンコードとワンホットエンコーディングで異なる動作が必要になる可能性があります（またはそうでない場合）すべてのオプションは両方に有効です、..）。 また、既存のhandle_unknownあります。これは、ワンホットエンコーディングにのみ関連し、通常には関連しません。 また、onehotエンコーディングの特徴の重み付けについてはhttps://github.com/scikit-learn/scikit-learn/issues/10518がありましたが、通常の場合には関係ありません（この問題は、最終的には問題ではありませんでした。 ColumnTransformertransformer_weights引数を使用した均等化）。 また、ワンホット用にdrop_firstようなものを追加する機能リクエストもありますが、これも通常のエンコーディングには関係ありません。

提案された変更が欠測値にどのように役立つかはわかりません。 そして、互換性のないオプションを持つことは、scikit-learnで頻繁に発生することです。 理想的ではありませんが、大したことではありません。

提案された変更が欠測値にどのように役立つかはわかりません。

それは、次のような助けにはならないが、それはそれはあまり複雑で、特に異なる符号化タイプに合わせた特定のオプションを持つようになります。

そして、互換性のないオプションを持つことは、scikit-learnで頻繁に発生することです。 理想的ではありませんが、大したことではありません。

現在は確かにまだ問題ありません。互換性のないオプションはそれほど多くありません（ただし、 sparse=True/Falseをencodingオプションに移動したこともあります）。 しかし、問題は、将来、scikit-learnのエンコーディング機能をどの程度拡張したいかということです。 もちろん、これは今答えるのが難しい質問です。
「アルファ符号化」のPRはすでにあります。 これは、新しいクラスUnaryEncoderを追加するのではなく、CategoricalEncoderに追加する必要がありますか？ そして、誰かが「バイナリエンコーディング」を追加したい場合はどうなりますか？ または「（平均）ターゲットエンコーダ」？

「平均ターゲットエンコーダ」はCountTransformer 、そのためのPRがあります;）

そのためのリンクはありますか？ 「CountTransformer」を検索しても結果は得られません

申し訳ありませんが、CountFeaturizer＃9614

それは確かに関連していますが、正確には平均的なターゲットエンコーディングではありません。 また、列を追加するのであって、置き換えるのではないので、文字列カテゴリデータの箱から出してすぐに機能することはありません（ただし、ここでは説明しませんが、そのPRに関するフィードバックが多くなります）。

なぜそれはターゲットエンコーディングを意味しないのですか？ しかし、ええ、ここではあまり流用しないようにしましょう;）

したがって、実際の質問の要約として、（この順序で！）答える必要があります。

1. 現在のCategoricalEncoderを維持しますか？ そうでない場合、アイデアはそれを異なるクラスに分割することです。エンコーディングのタイプごとに1つのクラスです（現在は「onehot」および「ordinal」エンコーディング）。

2. 複数のクラスに分割する場合、（理想的には？）「onehot」エンコーディングにOneHotEncoderを使用できますが、このクラスはすでに存在します。 では、新しい「onehot」エンコーディング（文字列をサポートし、さまざまなパラメーターを持つ）を既存のOneHotEncoderクラスに統合しますか？ それとも別の名前を選びますか？ （例：DummyEncoder）

3. 既存のOneHotEncoderに統合することを選択した場合、次の結果で問題ありません：OneHotEncoderの一連のキーワード/属性を非推奨にし、特定のユースケース（表示されている値の範囲内の表示されていない値を自動的に無視する）は不可能になります非推奨期間の後、もう。

上記の議論のほとんどは、質問3（CategoricalEncoder（encoding = 'onehot'）をOneHotEncoderに統合する方法の複雑な詳細）に関するものでした。 しかし、最初に最初の2つの質問の決定に同意しましょう。

私にとって他の要因は、誰もが現在の自動モードを
OneHotEncoderは奇妙です。 cooをcsrに変換する実装も
変。 それは再設計に値する。 そして人々に「もしあなたがホットになりたいなら
文字列をエンコードし、代わりにCategoricalEncoderに移動します」OHEのため、厄介です。
すでにカテゴリを対象としています...

時間。 OneHotEncoderは、使用できる方が効率的であるため、維持したと思います。理想的には、すべての奇妙な動作を取り除きます。 私はちょっとそれを非推奨にしたかったのですが、それから私たちはしませんでした...

私はちょっとそれを非推奨にしたかったのですが、それから私たちはしませんでした...

私のPOCPR（https://github.com/scikit-learn/scikit-learn/pull/10523）では、名前を除いて、OneHotEncoderのほとんどすべてを非推奨にしました...

それはそれほど効率的ではありません。 また、LabelEncoderにintの高速パスがある場合
範囲[0、n_values-1]で、正当化されれば、それで十分です。

@amueller 、エンコーディングに応じて最終的に異なる追加パラメータ（drop_first、nan処理など）が必要であり、エンコーディング形式ごとに異なる個別のエンコーダを使用することを正当化するという問題に納得していますか？

2週間後の春休みにこれを見てみますねその前に時間があるかどうかわからない：-/

これが間違った場所ではないことを願っていますが、現在の実装では、1つの列内にカテゴリと非カテゴリが混在するテーブルをどのように処理しますか？ https://github.com/pandas-dev/pandas/issues/17418から例をとる

次のデータフレームdf = pd.DataFrame([{'apple': 1, 'pear':'a', 'carrot': 1}, {'apple':'a', 'pear':2, 'carrot':3}, {'apple': 2, 'pear':3, 'carrot':1}, {'apple': 3, 'pear':'b', 'carrot': 1}, {'apple': 4, 'pear':4, 'carrot': 1}])について考えてみます。

  apple  carrot pear
0     1       1    a
1     a       3    2
2     2       1    3
3     3       1    b
4     4       1    4

DictVectorizerは、この場合に必要なものを正確に提供します。

    from sklearn.feature_extraction import DictVectorizer
    enc = DictVectorizer(sparse = False)
    enc.fit_transform(df.to_dict(orient='r'))

これは与える：

array([[ 1.,  0.,  1.,  0.,  1.,  0.],
       [ 0.,  1.,  3.,  2.,  0.,  0.],
       [ 2.,  0.,  1.,  3.,  0.,  0.],
       [ 3.,  0.,  1.,  0.,  0.,  1.],
       [ 4.,  0.,  1.,  4.,  0.,  0.]])

次の列の機能名を確認できます。

    enc.feature_names_
    ['apple', 'apple=a', 'carrot', 'pear', 'pear=a', 'pear=b']

新しいCategoricalEncoderに同じことをするオプションがあれば素晴らしいでしょう。

そのような混合ケースを扱うつもりはないと思います

残念です。 単純なサブケースの1つは、列が数値であるが、いくつかの欠落値がある場合です。 簡単な解決策は、NaNを空の文字列に変換してから、上記の例のようにDictVectorizerを使用することです。 これにより、値が欠落している場合の新しい機能が効果的に作成されますが、それ以外の場合は数値は変更されません。 これは非常に便利なテクニックだと思いました。

新しいCategoricalEncoderは同様のことを実行できますか？

ユーザーがNaNを別のカテゴリとして扱うことを許可することを検討しました
または類似。 しかし、それは任意の数値を処理することと同じではありません
文字列とは異なります。

いいですね。

確かに、2つのユースケースがあります。 数値を文字列とは異なるものとして扱うことが私にとって有用であった特定の例を説明しましょう。 より良い解決策があるかもしれません。

広範囲の値をとる整数の数値機能があるとします。 ただし、一部の小さな値では、正確な値が重要であると思われます。 値が大きい場合は、そうではないと思われます。 簡単な方法は、すべての小さな値を文字列に変換し、上記のようにDictVectorizerを実行してから、特徴選択を実行するか、お気に入りの分類子を直接使用することです。

それで、非線形離散化にそれを使用していますか？ 次のリリースは
固定幅のディスクリタイザーが含まれている可能性がありますが、ログから続きます
変換または分位変換は、あなたと非常によく似た動作をする必要があります
欲しい...しかし、あなたの設定では、ログ変換だけで十分かもしれません。

午後6時10分に2018年2月25日には、lesshaste [email protected]は書きました：

いいですね。

確かに、2つのユースケースがあります。 特定の例を説明しましょう
数値を文字列とは異なるものとして扱うことが有用であった場所の
私のため。 より良い解決策があるかもしれません。

の範囲が広い整数の数値機能があるとします。
値。 ただし、いくつかの小さな値については、正確な値が
重要です。 値が大きい場合は、そうではないと思われます。 シンプルな
行うことは、すべての小さな値を文字列に変換し、DictVectorizerを実行することです
上記のように、機能選択を実行するか、お気に入りを使用します
直接分類器。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment-368288727 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAEz60cmjwlDVKGyXc6oPyIC9oLbptSgks5tYQdvgaJpZM4RpUE8
。

@jnothmanひねりを除いて、ある意味ではそうです。 1 ... 1024の値のいくつかは意味があると思います。 つまり、22は、21または23とはまったく異なる特定の何かを示します。ログを取得しても、ここでは役に立ちません。 ただし、1024を超えるすべての値は数値のままにしておきたいので、これらの特定の値はあまり意味がないと思います。

ジェネリックの変数についてよく知っているようです
あなたが必要とするようなものに変身します。

午前20時37分に2018年2月25日には、lesshaste [email protected]は書きました：

@jnothman https://github.com/jnothmanある意味では、
ねじれ。 1 ... 1024の値のいくつかは意味があると思います。
つまり、22は、21またはとはまったく異なる特定の何かを示します。

1. ログを取ることはここでは役に立ちません。 しかし、私はすべての値を残したい
   これらの特定の値はあまり意味がないと思うので、1024は数値です。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/scikit-learn/scikit-learn/issues/10521#issuecomment-368295895 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAEz65bOdVB6k7rCAcgLBYz_NslxXWV0ks5tYSnggaJpZM4RpUE8
。

@jnothmanもう少し明確にするために、22が重要であることを私は知りません。 いくつかの値があるのではないかと思いますが、どれがかわかりません。 「文字列に変換」してから、DictVectorizerメソッドがこれらがどれであるかを発見するのに非常に役立つことがわかりました。

@lesshaste個別のカテゴリとしてのNaNに関する問題については、 https：//github.com/scikit-learn/scikit-learn/issues/10465を参照して
特定の非線形離散化または数値/文字列の混合エンコーディングについてさらに議論したい場合は、新しい問題を開いてください。 ただし、これは元の問題、つまりCategoricalEncoder / OneHotEncoderのさまざまなクラスでの命名と編成に焦点を当てたままにしておきたいと思います。

2週間後の春休みにこれを見てみますねその前に時間があるかどうかわからない：-/

@amuellerそれは結構です。 とにかくこれによってブロックされているPRに取り組む時間は今後2週間ありません。 その後、私もそれに取り組む時間が再びあるはずです。

@amuellerこれを見てみる時間はありましたか？

@amuellerは、OrdinalEncoderとOneHotEncoderでCategoricalEncoderを分割するためのPRに取り組んでいます（そしてOneHotEncoderの現在の引数を非推奨にしています）。

欠席してすみません。 大丈夫そうですが、実際に確認できるように2週間ください。 ありがとう！

@amueller問題ありません、私にとっても同じです:-)
しかし、私は今、これをもう一度見ることを計画しています。 ですから、これを見ていただければ幸いです。 PR（https://github.com/scikit-learn/scikit-learn/pull/10523）でやるべきことがいくつかあるので、まだ詳細に確認しないでください（アイデアを得るにはそれを見ることができます）しかし、私たちが提案するものの）。
時間をかける前に答えてもらいたい主な質問は、CategoricalEncoderを複数のクラスに分割しても問題ないかどうか、その場合はOneHotEncoderを再利用しても問題ないかどうかです（つまり、現在の（奇妙な）機能の一部を廃止します）。 これらの質問は、 https： //github.com/scikit-learn/scikit-learn/issues/10521#issuecomment-363851328およびhttps://github.com/scikit-learn/scikit-learn/issues/10521#issuecommentにまとめられています。 -364802471。

（そして、その部分に同意した後でも、PRでの実際の実装について議論することがたくさんあります:)）

PR https://github.com/scikit-learn/scikit-learn/pull/10523を更新し、レビューの準備をしました

私は慎重に戻ってきたと言います;）

IMHOで最も重要なことは、ここで説明するすべてのエンコーダー用のユニバーサルAPI（つまり、パラメーターと動作パターン）です。

PS https://github.com/scikit-learn-contrib/categorical-encoding ？

category_encodersパッケージでは、すべてのエンコーダーにcols引数があります。これは、古いOneHotEncoderのcategorical_featuresと同様です（ただし、まったく同じ種類の値を受け入れるわけではありません）。 たとえば、 http ： ください。
これは、 https：//github.com/scikit-learn/scikit-learn/pull/10523でcategorical_features廃止について話し合っている現在の議論に関連しています。

残りの部分については、実際には競合するキーワードはないと思います（これらには、現時点ではsklearnに追加しないデータフレームに固有のキーワードがいくつかあります）。 OneHotEncoderとOrdinalEncoderの名前は、少なくともcategory_encodersパッケージと一致しています。