バックテストのカーブフィッティング対策を考えてみた
バックテストで勝って勝って仕方ないという話
まあカーブフィッティングしてるからなんですけどね！
ということで、対策をいろいろと考えてました
まあしかし考えてはみたものの、実際にテストして勝ったからって１００％カーブフィッティングしてるというわけでもないですし、じゃあ負けてたらいいのか？ってなったら、それはもう負けてるからカーブフィッティングはしてないけどロジックとして役に立たないじゃん……ということに
が、しかし何も対策してないと、全く勝てないのに本番で回してしまった結果破産しました……なんてことになっても困ります
そんなわけで、とりあえずの方法として、過去のレートは2017年3月からあるわけですが、2017年3月から2018年3月までの一年間でバックテストを行い学習用のデータを作成
んでもって、今度はそのデータを使って2018年3月から2019年3月までの期間でテストをしてみた結果……それまで方ていたロジックが……無事負けました！
よし、これでオッケー！というのも変ですが、とりあえずこのやり方だと一応判定にはなるのか？ということで最低限のチェックはできてる？……のか？
な状態
同じ理屈で、2017年3月から2019年2月末まででデータを作って、2019年6月頭までのレートでテストした結果、一応3月からの収支がプラスになってたからいいのかなあ？
と思ったので実際に回してみたら、ものすごい勢いで残高が減っていってワロタｗ
な状態に
そんなわけでどうしたものかと考え中
バックテストのレートがローソク足なんで、ローソク足からTick作ろうかなあと思ったけど、それ結局データ数が多くなるだけで毎度同じテストになるだけやん……ということになってさらに悩む
……で、思いついたんですが、じゃあもういっそTickを複数パターン作っちゃえばいいいんじゃないかと
OHLCの条件だけ守るようにいろんなパターンのTickを作ってテストして、全部の結果がプラスならいいんじゃね？
ということをひらめいたので、ちょっとやってみようかと
しかし現時点でも重いロジックはテストに30分かかってるんだけど、それをTickでやるとなったら一体どれだけ時間がかかるのか……
テスト高速化のためにいろいろとやったけど、今いち早くならないんだよなあ……
なんかうまい方法がないか考えないと
