INTP型のブログ

苦味があるな?

実運用してみての課題

完全に水曜日平日だと思ってたのだけど、祝日だったのでこれ幸いということで自動売買のシステム完成させた

 

完成と言ってもログ取らないし、例外処理もしてないので非常にあれだけど、とりあえずローカルで動かせば特定のタイミングで売買処理をしてくれる

 

で、動かしてみてこれは「問題だなー」となったのは

 

  • Please enter the order rate within the range of the order acceptance width.

 

っていうエラー

 

要は注文した価格が、現在価格に対して値幅なさすぎるというエラー

 

注文価格の計算を行っている段階で、値動きが注文価格に対して注文が行えないような値動きをしたために起きてるっぽい

 

いうても処理時間は1秒以内には終わるのだけど、ミリ秒とかの世界での戦いにはなってしまうっぽい

 

これを避けるためにはより計算速度を上げるか、価格計算のロジックを変えないと厳しい

 

有名なbotterが言っていたけど、「自分に有利な指値は通りにくいが、自分に不利な指値は通りやすい」とのことで、まさにそのような感じになっておりしんどい

 

でもどうしても機械学習のロジックが間に挟まる都合上、普通の自動売買のシステムより注文速度は落ちちゃうんだよなー

 

一応まだ処理速度を改善できる余地は残りまくって入るけど、それを改善できたからと言ってどうなるかは微妙

 

とりあえず今日一日動かしておいてどうなるか見てみようかなという次第

 

見てると「この指値通ってたらって勝ってたのになー」というのが多すぎて歯がゆ過ぎますわね…

 

メモ

とりあえず処理ロジック変更したほうがいいと思った

ohlcv取得→モデル処理→売買処理

を、

ohlcv取得→モデル処理→ohlcv取得→売買処理

とすることで、注文価格の軸としている終値を更新すれば、通りにくい指値が改善されるという考え。

↑これやめたほうがいいわ、価格不安定になりすぎてロジックが破綻しかねない

 

メモ2

決済処理→注文処理

で、建玉数に応じて注文するかどうかを判断してたんだけど、決済処理→注文処理の間に決済処理が適応されて、建玉があったはずなのに注文処理が実行されてしまう

バックテスト的にはこのケースは注文処理実行されないはずなので、あんまよくない仕様だなと言う感じ(一応最大ポジションに余裕がある場合は注文が実行されるので、まあ別に問題ないといえば問題ない)

そもそもapi叩く回数を減らせるなら減らしたほうがいいはずなので、なんとかしたいなーという思い

あと、バックテストの際に、指値価格が低くなりすぎている場合は、定数で処理するってロジックを組み込んだ場合、どれぐらいのスコアになるのか見ておきたいなと思った

 

メモ3

各足の最初に注文が残っていたらキャンセルして新しく注文を行うってロジックが走るようになっているのだけど、この処理のせいでその後の決済処理まで値幅が不利に動いて注文が通らなくなってしまっている

エントリ通らないのは許せるけどイグジット通らないのはそこそこやばいので、メインの処理をする前の最初段階で注文のキャンセルは済ませてしまうよう変更するべき

↑クラス設計的に直すのクソ面倒くさくてワロタ、ワロタ……

 

メモ4

約定ズレは想定していたよりもかなり出ている。およそ0.01%~0.02%は出ている印象

システム的にかなり小さい値幅をとっていくことになるので、このズレはかなり大きい気がする

バックテストに組み込んでみてどの程度性能が下がるか調査したほうが良さそう

↑あんまり信じたくないけど、約定ズレ考慮するとクソ雑魚になるな……ってか、高頻度でこんだけずれたらどんなシステムでもきつい説あるわ。時間軸いじったほうがいいかもしれない

 

メモ5

冷静に考えると決済とか注文は全て並列処理にしたほうが絶対いいわな

並列処理で実装するのめんどいからとりあえず順番に処理するようにしたけど、ここ変えるだけで全然速度変わるわ

だるくて触ってなかったけどpybottersの使い方みるかー……

 

メモ6

取引所を変えるべきだなと思った

bitflyerが勝ちやすいって話をよく聞いてたけど、自分のシステムが勝てるところ探したらたしかにここだなってなった

その場合バックテストから全部やり直しになるんだけど、それぐらいの価値は余裕でありそう