ゆきのぶ日記
2006/08/10(Thu) [長年日記]
■ [シストレ] ボラティリティに基づくポジションサイジングとストップ設定
『システムトレードでマイペースなプログラマ・ライフ』の『ストップのテスト結果』と『ポジションサイジングのテスト結果』に触発されて，運用中のシステムのポジションサイズとストップを決定する方法を変更してみた。
今までは固定量のポジションサイズと固定幅のストップだったけど，今回下記の方針に変更してみた。
- ボラティリティが低い場合はポジションサイズを大きくし，ストップ幅を小さくする。
- ボラティリティが高い場合はポジションサイズを小さくし，ストップ幅を大きくする。
- ストップロスになった場合の損失額は常に一定とする。
Before:
After:
ぱっと見た感じ，リスクは変わらないがリターンは倍になっている。使えそう。
『複利の魔力』のようなことも，今度試してみよう。どうなるか楽しみだ。
2006/08/17(Thu) [長年日記]
■ [シストレ] 口座残高に基づくポジションサイジング (2)
再挑戦。
前回は違いが分かりづらかったので，今回は違いを際だたせるため，ポジションサイズを 5 倍にした。
ポジションサイズは，おおよそ下記のように決めている。
ボラティリティ値
= ボリンジャーバンドの上の価格 - ボリンジャーバンドの下の価格
単利用ポジションサイズ
= ポジションサイズ定数 * トレードあたりの損失許容額定数 / ボラティリティ値
複利用ポジションサイズ
= 単利用ポジションサイズ * 初期口座残高 / 現在口座残高
そして結果。
単利版:
複利版:
以下，いろいろと考察。
- 資産曲線（紺のグラフ）の形
- ぱっと見で，後半は複利版の方が変動が大きくなっている。これは，複利用ポジションサイズが機能していることを示している。
- ポジションサイズ曲線の形（緑のグラフ）
- ぱっと見で，単利版では後半になるとポジションサイズが減るが，複利版では増えている。これは，複利用ポジションサイズが機能していることを示している。
- プロフィットファクターの低下［2.07→1.64］
- このシステムは，後半になるとパフォーマンスが悪化するので，その影響を受けている可能性が高い。
- 利益の向上（380% → 573%）
- 利益は向上しているが，理想的なシステム（資産が直線的に伸びてゆくシステム）なら 380% の 2 乗で 1444% になって欲しい*1 から，向上しているとは言い難い。
- ドローダウンの深刻化（4.3 倍）
- 利益は 1.7 倍にしかなっていないのに，ドローダウンは金額ベースで 4.7 倍にもなっていて，ひどい成績だ。後半のパフォーマンスの影響を受けている可能性が高い。なお，図中の drawdown % は初期口座残高に基づいている。
- 損益の非対称性
- 複利版では，損益の非対称性の影響を受けるため，十分な勝率とリスクリワードレシオが必要なはず。単利版で安定した利益を出せるだけでは，複利のメリットを享受するには不十分なはずだ。
- まとめ：複利が有利な場合，不利な場合
- 単利ベースで収益が十分であり，かつ安定しているシステムほど，複利にすると伸びるかと思う。逆に，単利ベースで安定感がないシステムは，複利にしても伸びず，逆に損失になってしまうかも知れない。
うーん，特に結論らしいものは出ないけど，足りないものが見えてきたような気がする。今後とも考えていこう。
*1 かなり自信なし。極限や微積分を徹底的に忘れていると自覚した。
2006/08/26(Sat) [長年日記]
■ [楽器] 演奏会
数ヶ月の練習を経て，いよいよ今日は本番。
Music Factory Festival で演奏してきた。
ちゃんと演奏できる自信はあまりなかったけど，本番が一番ウマくできた。
いやー楽しかった。もっと演奏したくなってくる。
2006/08/27(Sun) [長年日記]
■ [シストレ] 注文の自動化
今日は，シストレのセミナーに行ってきた。色々と得るものがあったり，足りないものが判ってきたりしたので，私のこれからの方向性に影響しそうだ。
セミナー後は懇親会があったので，他の人のシステムの話を聞いたり，私のシステムの話をしたりしてきた。普段，周りの人とシストレの話をすることなどないので，これは楽しかった。
その中で出た話の一つに，注文の自動化があった。
私自身は，シストレなのだから発注は当然自動化するものと思っていたけど，注文を自動化している人はほとんどいなかった。実際のところ，敷居は結構高いようだ。
そこで，注文を自動化できそうな方法についてまとめてみた。
- キーボード・マウス操作の自動化
- ロケットマウスや UWSC を使って，キーボード・マウス操作を自動化する方法。人間用のインターフェースを提供しているすべての業者に対応できるが，作るのは面倒で，トラブルも発生しやすいと思う。また，価格の取得は出来ないので，別の方法を組み合わせる必要がある。
- HTTP クライアントの自作
- Web ベースで取引できる場合に，それを真似る方法。上に比べるとやや安定感のある方法だと思う。Perl だと WWW::Mechanize あたりを使うと，ラクに作れる。
- 業者以外が提供するサービス
- 上記のような方法を第三者に委託する方法。オートレなど。使ったことがないので詳細は知らない。
- 業者が提供する API を使う
- 一番スマートな方法だが，業者によっては手数料が必要なのが難点。手数料のない業者を見つけるのが鍵だが，そのような業者では他の参加者もシステムを使ってる率が高いので，システムの内容によっては約定の具合に難があるかも知れず。
● たっきー [なんか過去のブログ読んでるとワクワクしてきますねー。 思い立ってから実行までが早！さすがプログラマさんです。 関係な..]