kaggle zillow challenge
現在のコード
前回までは複数のモデルを学習して得たモデルの予測値の平均（アンサンブル？）を用いていた。
今回はそのアンサンブルするモデルを追加する事にする。
Gaussian Process Regression:メモリエラー、見送り
KNearest Regressor:OKだがとても重い
Kernel Ridge Regression:メモリエラー、見送り
Support Vector Regression:OKだがとても重い
Random Forest:OK
Linear Regression:OK
全てsklearnからのモデルを利用。
パラメータはとりあえず試しなので、基本はデフォルト設定を利用した。
ひとまずOKかつ重くもないRandom ForestとLinear Regressionを加えて
試したところ：0.0677271-> 0.0664433。
OKだが重いモデルも適用したところ0.0659825（やっとサンプルベンチマークを超えられた
Adaboost、GradientBoostも追加したところ0.0655690
次に、stackingを試してみる。
これはベースモデルの予測結果を特徴抽出結果と捉えて入力に加える事で、性能を向上させる手法である。
大雑把な手法は以下である：
１．trainデータをsplitして得たtrain_fold, test_foldの組み合わせに対して、train_foldで
訓練したモデルでtest_foldを予測した結果を元のtrainデータに足したものをtrain_meta
として保存。これを各ベースモデルに対して行う。
２．続いてtrainデータを全て利用して学習したモデルでtestデータを予測した結果を
元のtestデータに足してものをtest_metaとして保存。これを各ベースモデルに対し行う。
３．train_metaへ学習を行い、test_metaへ予測を行った結果を最終結果とする。
ー結果0.0656203でstackingしない時より性能が落ちてしまう。
現状のstackingは2foldで行っていたので、追加して５foldで試してみる。
結果：0.0656738で改善せず。
もしかすると、stackingは今回の問題ではあまり効果がないのかもしれない。
むしろ各月毎に予測しなくてはいけないのに、全て同じ値を用いている方が大きな問題かもしれない。
ceresのLocalParameterization
ceresで良く使われるLocalParameterizationの意味について。
ある対象の状態を定めるパラメータは、最適化時にはoverparameterizedな場合が多い。
例えば３次元空間内で描かれるある球面上に存在する点のパラメータを考えた時、
ある点周りの微小移動に関していえば、その接面上の移動を考えれば十分であり、
法線方向の移動は無視しても問題ない。
その場合、実際に扱う次元は接面上の２次元空間のみであり、最適化がしやすくなる。
こうした考え方を適用可能にするのがLocalParameterizationである。
実際は、与えられているパラメータブロックに対して、
微小移動に対する計算を関数として与える事が必要になる。
しかし基本的な微小移動関数はすでに定義されているので、それをただ用いるのが
一番良いやり方ではある。
アジャイル？な開発プロセスについて
twitterか何かに流れていたのだが、
四輪自動車を作成する事を考えた時、直接車の車輪や車体などの部品を作り上げて最後に合体させるのではなく、
まず相対的にシンプルな自転車から初めて、次に二輪自動車、最後に四輪自動車というふうに
発展させていく事が良いという図があった。
たしかに直接四輪自動車の部品を１つ１つ作り上げて合体させる場合、合体させるまで「走る」という機能を
機械に持たせる事ができない。
つまり、実現したい機能が「走る」事に関連している場合、それを最低限実現する機械（自転車）を開発して、
その後は「走る」機能を発展・改善していくプロセスを辿る方が良いという事になる。
これはシステム統合テスト（あるいは早期の市場でのテスト） のしやすさを言っているだと思っているが、
あるいは何か機能（「走る」）を作る時に、それを実現する機械を大きく１つ作れば良いと考えるのではなく、
その機能に関してどのようなユースケースがあるかを全て吟味して、発見したユースケース間をパスを
繋いでいくように細かく作っていく方がビジネス的にチャンスも多く良いという事かもしれない。
研究などにおいても大テーマを小テーマに分割して、各小テーマを論文として量産し食い繋ぎつつ、
最も重要な大テーマに迫っていくというのは良くある話ではある。