ランダムフォレストと検定を用いた特徴量選択手法 Boruta

特徴量選択とは

特徴量選択(Feature Selection, 変数選択とも)はデータサイエンスにおいて非常に重要である。 Kaggle等のコンペティションではひたすら判別の精度を重要視するが、実務上どうしてそのような判別をしたのかという理由のほうが大事である(回帰問題も同様)。 例えば、なにかの製造工程をイメージしてみよう。 当然欠陥品は生じるだろうが、この欠陥品を見分けるシステムよりも欠陥品を減らせる改良のほうが良いだろう(もちろん見分けるのも大事だが)。 そこで、判別においてどのような特徴量が重要だったか選ぶことができれば、改良への糸口が見えてくるだろう。

また、特徴量選択した結果、モデルの学習や推論が高速化されたり、過学習しづらくなったり、結果判別の精度が良くなったりする。

Borutaとは

ランダムフォレストと検定を用いた特徴量選択の方法の一つである。 Witold R. Rudnicki, Miron B. Kursaらが考案。

R実装 CRAN - Package Boruta

Python実装 (バグあり。まとめ後に補足します。)(アップデートされてました pip install Borutaしましょう)

github.com

(名前の由来はスラヴ神話の森の神の名前らしいです。こんな見た目してます。)

このBorutaという手法は経験上非常に強力で、判別や回帰の性能が著しく低下したことはない。低下しても誤差の範囲内。むしろ性能が良くなることが多い。

Kaggle Masterになった日記

Kaggle Masterになった

"Feedback Prize - English Language Learning" (以下FB3) で金メダルを取得した結果、メダルの条件を満たし、Kaggle Competitions Masterになることができた。FB3については後で思い出を語ることにしよう。

Kaggle Competitions Masterになるための条件とは金メダル1つと銀メダル以上2つである。実は過去に金メダルを取得したことがあったので、FB3では銀メダルでもMasterになることはできたのだが、2枚目の金メダルでmasterになることができて非常に嬉しい。実力を示せてよかったと感じた。どうやらKaggle Masterはアクティブユーザーの上位1%に入る実力らしい？

金メダルが2枚あるとちょっとプロフィールが強く見えないですか？そうでもない？

お気づきの方もいらっしゃるかもしれないが、今まで参加したコンペは3つとも自然言語処理に関するコンペである。 結果的にということもあるが、自然言語コンペに絞って出場することで素早くKaggle Masterになることができたと思う。

チームメイトに恵まれKaggle Competitions Expertになった日記

はじめに

日記です。Kaggleを初めて2つのコンペに参加し無事Expertになったので、つれづれなるままにPCに向かひて、心にうつりゆくよしなしごとをそこはかとなく書くことにしました。 技術的に有用な情報はありません。運が強く味方してくれたため再現性はありません。

Expertになるまでの戦歴

kaggle戦歴。NBME 27位 で 銀メダル、PPPM 8位 で 金メダル。

NBME27位で銀メダル、PPPM8位で金メダルを取得したことにより、銅メダル以上2つというExpertの基準をクリアした。

これだけ見るとKaggle上手すぎぃ！次でMaster昇格か？という感じ。しかし後述するようにめちゃくちゃチームメイトに恵まれて運も良かったのが理由である。ソロだと銅メダルもかなり怪しい:pien:。

kaggle notebookで`pandas.read_pickle`ができない原因と対策法

背景

最近kaggleを始めて、困ったことに遭遇した。しかも調べても対策法を見つけられなかったため、自分の対策方法を記録に残すことにした。

遭遇した問題は以下のような状況で発生する。

1. kaggle notebook以外の環境でpandas.DataFrameをto_pickleで保存する。

2. kaggle notebookにてpandas.read_pickleをしようとすると、以下のエラーが出て読み込めない。

   • ValueError: unsupported pickle protocol: 5
   • AttributeError: Can't get attribute 'new_block' on <module'pandas.core.internals.blocks'

本ブログでは原因を解説したあとに手っ取り早い対処方法を紹介する。

解決策だけ知りたい方は、以下の手っ取り早い対処法までスキップして頂いて問題ない。

Visual Studio Code 等のアプリで command + [ (open bracket) がmacOSに吸われるニッチなバグの解決

状況

Macを初期化して再セットアップしたら、VSCodeで command + [ (open bracket, left bracketとも) が効かなくなった。 プログラミングしているときにこのショートカットを多用しているのでめちゃくちゃ困る。indentができなくなった！しかもshift + command + [のようなショートカットもすべて効かなくて困った。タブ移動もできねぇ〜〜〜〜！ しかもよくよく確かめるとElectron製のアプリ全般で効かなくなってる。これは最悪である(一部は反応するけど意図した挙動でないことになった)。

もし、これを読んでいるあなたもお困りならば次に進もう。 自分の知る限り一番シンプルな解決策をここで提供する。

このバグが起こりうる環境等については後で述べる。

直し方

以下のショートカットをなにか別のものに変えた後、OSを再起動する。

システム環境設定->キーボード->ショートカット->キーボード->次のウインドウを操作対象にする

デフォルトでは以下のようになっているはずなので、⌘@から適当なもの(例えば ⌘` )に変える。(無効化しても良いかも。未検証。)

変更すべき設定欄

クリックレートやコンバージョンレートといった二項母集団の母比率の信頼区間 精密法のPython実装

前提

本記事ではクリックレート(CTR)やコンバージョンレート(CVR)といった二項母集団の母比率について信頼区間を計算するPython実装を与える。データ数が少ない状況においてはCTRやCVRだけではなく、その不確実性も考慮し比較、議論するのが望ましい。 二項母集団の母比率の信頼区間の算出方法は近似法がメジャーであるが、データ数が少ない状況においては誤差が大きくなる。ここでは精密法を用いて算出する。

本記事で求めるものを厳密に定式化するなら以下のようになる。

ベルヌーイ分布に従う確率変数がが個存在する。はのいずれかを実現値として取る。

現実で例えれば、広告を見た人が人いて、それぞれの人について広告を見たら1、広告を見てなければ0ということに対応する。広告を見る確率はである。

次に広告を見た人数をとする。も確率変数であり二項分布に従う。

の実現値をとする。

データ

n回試行してs回成功した(n回表示してs回クリックされた)。

求めたいもの

の信頼区間の上限と下限 (信頼係数 1- )

病気に備える保険にはいつ加入すべきか？ 罹患の累積確率と許容リスクから考える

背景

保険には入っておいたほうが良いとは聞くが、商品は膨大で何を保証すべきか、いつ入ればいいのかなど考えることは多い。

本記事では自分のメモの意味合いも含めて、

1. 何を保証すべきか？
2. いつ入ればいいのか？

を検討していく。

そもそものきっかけは、節税のために行った保険の契約だった。

ちなみに節税のために契約した保険とは、明治安田生命のじぶんの積立という商品である。 詳しくはリンク先を参照していただきたいが、実質ただの貯金である。貯金をしながら一般の生命保険料控除で税金が安くなるという税制の穴を突いたような商品である。

ただ、契約をするには対面で生保レディーの話を聞く必要があり、ここで他の保険にも入ってもらうことが明治安田生命の真の目的である。(この商品だけ買われると多分倒産する)

そういうわけで、「じぶんの積立」だけ入るのも居心地が悪く、ちゃんと保険について検討してみようと思った次第である。 特に男性の60%が一生のうちにがんにかかる、なんて言われると他人事ではすまない。

早速結論

自分の場合は

• 55歳にがん保険に加入
• 70歳以降に脳卒中に備える保険に加入

という結論になった。 以下では、この結論に至った理由を説明していく。

intel macbookでスリープ中に電源が切れる問題とその解決方法

概要

Intel CPUのMacbook proの電源を切った覚えがないのに、蓋を開けると電源の付く音が流れることが数回発生した。しかも決まって前回は異常終了したという警告。

そこで原因を調べ、暫定的な解決法をここにメモをする。日本語では情報が出なかったので誰かの助けになれば嬉しい。

(ちなみにIntel macの15,16インチモデルばかりに発生している様子だった。)

エラーメッセージ

自分の環境では以下のようなエラーメッセージが発生していた。

Sleep transition timed out after 180 seconds while creating hibernation file or while calling rootDomain's clients about upcoming rootDomain's state changes. と、あるようにスリープ中に異常が起きているようだ。