| 勝てるアルゴリズム探すのに暫く時間かかりそう |
|
|
色々テストしていて、ペイオフレシオを僅かに上げる方法を見つけました。現在値と当日の始値との比率をとって、それが低めの銘柄を買うようにすれば、ペイオフレシオは上がってくれるようです。ただあまりにその比率が低すぎると、その分の下げがトレンドになってしまって、結果的に勝率が下がってしまうようです。逆張りで勝率を上げるのは何だかちょっと難しそう。
結局今のところ、まだ勝てるアルゴリズムは見つかっていない状態です。時価総額が大きい銘柄のログばっかりとっていたせいか、ボラが小さすぎです。これじゃあ出来高を見て判断というわけにもいかないし。
// I I I I //
// I I I I //
// I I I I //
// I I I I //
// I ('A`)I I I //
// Iv( )vI I＿＿_I //
// ￣( (￣ ￣￣￣ //
| |
|
8月3日（木） | トラックバック(0) | コメント(0) | 日記 | 管理
|
| 売買アルゴリズム作るの難しい |
|
|
昨日は非同期処理に問題を見つけたのでそれを修正。テストでインボイスを1株買ったら10円抜かれた。昨日の夜に色々な売買アルゴリズムでバックテストをしてみる予定だったのですが、夏風邪で寝込んでしました。
お昼にバックテストできればいいのですが、ためしにやってみたところ、バックテストの処理が重くてログをとる方のプログラムに遅延が発生してしまいました。そこで、バックテスト処理をする方のProcessPriorityClassをBelowNormalにしてみたところ、ログをとる方も遅延は起こらず、バックテスト処理の方もまあ何とかギリギリ使えるような速度で動いてくれました。とはいえ5日間の検証に30分もかかるような状態(´･ω･｀)。
で、色々なアルゴリズムを検討してみたのですが、これがまた全然ダメ(´･ω･｀)ｼｮﾎﾞｰﾝ。先物の方で使えるアルゴリズムを現物に移植してみたところ、勝率は50%程度だけどペイオフレシオが低くてトータルでかなりやられてしまうという結果になりました（しかも手数料を加味していない状態でこの結果）。現物のボラと先物のボラは全然違うので、まあこういう事態は十分予想していたのですが。どうも損益の平均値を見てみると、ちょうどティック幅分だけ負けているような感じで、それが蓄積されて大きな負けになるという感じです。全然ダメですねえ～。
徳山式も検討には入れているのですが、今のところは時価総額が大きめの銘柄のログしかとっていないので、徳山式をテストすることはできません。できれば自分のアイデアだけで構成された売買アルゴリズムを動かしたいと思うのですが……その方が面白いし。
, -‐ '´￣￣｀ヽ､
／ :／" ｀ヽ ヽ ＼
/ / ヽ ヽ.. ヽ
l { l , ｰ-j从:ヽ.. ヽ
| i ﾙ{ﾚ' ●｀ ｌi! ﾄ､ ',
／⌒)i"● ⊂ｌ| ||ノ ｌ
/ ｙi ﾍ⊃ ,__, l| | ｌ
（ ／ｽ､,ゝ､_ ｀´ ィ<| | ｌ
| |
|
8月2日（水） | トラックバック(0) | コメント(1) | 日記 | 管理
|
| 【棚ボタ】久々に儲けた～。 |
|
|
今日は、約定の検出処理や決済処理がきちんと出来ているかどうかを確認してみました。自動売買で発注を担うサブルーチンを直接呼び出せるように作っておいて、手動で発注してみました。案の定、色々なところにバグが潜んでいたので修正しました。偶然にも滅多に出現することが無さそうな排他処理の問題を発見できたのが良かったです。その他の間抜けなミスも含めて色々発見できました。
テストに用いた銘柄は8925 アルデプロと9448 インボイスと8571 ニッシンですが、出鱈目に注文したりトラブルに遭ったりした割には利益になりました（とはいってもテスト用に最低売買単位で売買してるので500円程度の儲けですが）。久々に儲けた～。
|
|
∧＿∧ ∧＿∧
（ -д-） （・д・ ）
─/ ∪ ∪─── /^/^と ）
し、＿）_） ⑩ （__（＿）ノ＼
⑤ ① ＼
| |
|
7月31日（月） | トラックバック(0) | コメント(0) | 日記 | 管理
|
| ワイヤレスネットワーク切れすぎ |
|
|
以前にも触れたのですが、ワイヤレスネットワークがあまりにも切れ易すぎ。BUFFALOのWLI-CB-G54Lというのを使っているのですが、ちょっと重い処理をさせるだけで接続が切断されます。自作アプリの起動時のログイン処理やファイルの読み込み処理を早くしようと思って、プロセスのプライオリティをabove normalにしたら、たったそれだけで接続が切れました。なんじゃこりゃあああ('A`)
( _, ,_)
＿(__つ/￣￣￣/＿
＼/ ./
￣￣￣
／＼
..／ .／|
∴＼／.／
_, ,_ﾟ∵ |／
(ﾉﾟДﾟ)ﾉ どいつもこいつも！
/ /
￣￣￣￣￣￣￣￣
| |
|
7月29日（土） | トラックバック(0) | コメント(0) | 日記 | 管理
|
| 約定の処理もちゃんとしなきゃいけないっぽい |
|
|
証券会社への発注の際に、約定とかの面倒な処理は避けようと考えていたのですが、どうやらそういうわけにもいかないようです。例えば、もし売買シグナルを出すアルゴリズムに問題があって、買い注文を発注してそれが約定する前に決済注文を出してしまった場合、買い注文だけが残されてしまう可能性があります。引け間際では下手をすると意図せずに持ち越してしまって大変な目に遭ってしまいそうです。やっぱり約定のチェックはしないとだめなのかな？UWSCとかを使っている人達はこの問題をどう解決しているんだろう？徳山式みたいな方法だったら時間にかなり余裕ができるので、変な注文が多少あっても何とかなるかも知れませんが。
25日や27日に起こったDDE関連の問題を解決する方法を思いつきました。RSS.exeのほかにもうひとつ、RSSで得た情報をそのまま垂れ流すようなDDEサーバー(例えばExcelとか)を予め用意しておいて、自作アプリの起動時に両方のDDEサーバーを接続し、RSS.exeとの接続がダメになったら予備のDDEサーバーからデータを取得するという方法です。これならば、RSS.exeとの接続がダメになった後の再接続にかかる時間を節約できるので、ログが途切れる心配も少なくなると思います。
最初は単純に別のスレッドでRSS.exeに対してDDEリクエストを送信しようと考えていたのですが、それだとトピックやアイテムが多すぎて実用にならないことがわかってしまったので、こういう方法を考えたというだけのことです（実際にはそれだけではなくて、マルチスレッド化したらイベント送信を要求するところでデッドロックっぽい現象が起こってしまったということもあります。マルチスレッド化していなくてもsynclockを使っただけで不定期に固まるので、ライブラリ側の問題なのかも知れません）。
ただDDEサーバーを今から作るとなると、それはそれで面倒な感じです。それにこれをやったからといってうまく行くとも限らないので。
デバッグ中に、自作アプリを停止させずに変数だけ閲覧することってできないのかな～。とりあえずそれだけあれば何か原因は掴めそうなんだけど。
週末資産=1,008,158
前週比=-148
↑報告の意味が余り無いけど。
△
( ･∀･) ゆうらゆらぁ～
(υυ)
|ノ
| |
|
7月28日（金） | トラックバック(0) | コメント(0) | 日記 | 管理
|
フォトログ表示
