株価 - バックテスト（ストキャスティクス版）！
Updated:
Ruby + MySQL で自作した株価取得のシステム。 全市場（東京・大阪・名古屋・札幌・福岡）の全銘柄の1983年からの全取引データを取得しています。
以前は、売買サイン発生後の株価の挙動を集計しました。
今回は、「MACD（移動平均・収束・拡散法）シグナル」での計算で発生した売買サインデータを基に、仮に取引をしていた場合にどのような結果（損益）になるのかを検証していました。 通常、このようなテストのことをバックテストと言います。
全体的にどんな傾向があるのかを把握するのと、Ruby (+ MySQL) の学習が目的です。 ※興味が無ければスルーしてください。
以下に、前提条件・検証結果を掲載します。
１．前提条件等
１．売買サインの定義
-
ファスト・ストキャスティクス
- Fast%K が A%以下の圏域で Fast%D を上抜けたら買いサイン
-
Fast%K が B%以上の圏域で Fast%D を下抜けたら売りサイン
-
スロー・ストキャスティクス
- Fast%D が A%以下の圏域で Slow%D を上抜けたら買いサイン
- Fast%D が B%以上の圏域で Slow%D を下抜けたら売りサイン
としました。 ※A, B の値は [ 20, 80 ] や [ 25, 75 ] を使用することが多い ※Fast%K : 5 or 9 or 14, Fast%D : 3, Slow%D : 3 とすることが多い。。 また、調整後終値（株式分割があった場合の調整値）を考慮していません。
２．検証銘柄と検証期間
2012年3月31日現在上場している全市場の 3,579 銘柄を対象に、2000年1月1日から2011年12月31日の株価データを使用して検証しました。 また、複数の市場に上場している銘柄については、優先市場のみで検証しました。 ※全取引件数は 7,901,550 件
３．注文条件
- 資金は 5,000,000 円に設定
- 無ポジション中に買いサイン発生で、買いエントリ
- 買いポジション中にストップロス発生で、エグジット
- 買いポジション中に売りサイン発生で、エグジット
- 無ポジション中に売りサイン発生で、売りエントリ
- 売りポジション中にストップロス発生で、エグジット
- 売りポジション中に売りサイン発生で、エグジット
- エントリ・エグジットは翌営業日の始値で行う
- 手数料は、SBI証券の手数料（スタンダードプラン）を使用する。
- リスク率は 0.05 に設定
- ストップロス率は 0.4 に設定
- スリッページは 1 に設定
- 呼び値も考慮
- エントリ時は、毎回資金残高中で投資可能な最高額を投資
- エントリ時に資金残高が不足する場合はエントリしない。
各種用語については、各自でお調べください。 検証アルゴリズムは以下の書籍（エクセルでの検証）も参考にしています。
４．検証方法
- 各銘柄について、対象の期間内のデータで売買サインの発生を検証する。
- 各銘柄について、上記３の「注文条件」にしたがって、バックテストを行う。 算出項目：売買単位、手数料、損益、総損益、資金残高、最大ドローダウン
- 全銘柄のバックテスト結果を集計する。 検証項目：総損益、利益、損益、プロフィットファクター、トレード回数、 勝率、勝ちトレード数、負けトレード数、最大利益額、最大損失額、 総手数料額、最大ドローダウン、 平均損益額、平均利益額、平均損失額
２．検証結果
以下は、[ Fast%K : 5日, Fast%D : 3日, Slow%D : 3日, 高率 : 80%, 低率 : 20% ] で計算した結果です。
１．バックテスト結果
買い・売り両方のエントリを想定して検証しています。 全銘柄のトータルなので、莫大な数値となっています。 やはり、総損益もマイナスとなってしまいます。 また、買いエントリだけ、売りエントリだけを想定して検証した結果は、金額に差が出るものの比率は同じような結果になりました。
[ Fast ]
−−−−−−−−−−− [ TRADE(ALL) ][ TRADE(LONG) ][ TRADE(SHORT) ]
総損益 -1,053,394,939 -1,329,715,092 276,320,153
利益 10,562,612,538 5,014,291,987 5,548,320,551
損益 -11,616,007,477 -6,344,007,079 -5,272,000,398
プロフィットファクター 90.93 79.03 105.24
トレード回数 203,700 104,225 99,475
勝率 8.58% 6.98% 10.25%
勝ちトレード数 17,483 7,279 10,204
負けトレード数 186,217 96,946 89,271
最大利益額 1,183,260 860,422 777,240
最大損失額 -182,685 -159,152 -152,136
総手数料額 490,687,927 251,174,300 239,513,627
最大ドローダウン -185,014 -159,086 -154,304
[ Slow ]
−−−−−−−−−−− [ TRADE(ALL) ][ TRADE(LONG) ][ TRADE(SHORT) ]
総損益 -2,843,619,365 -2,550,446,587 -293,172,778
利益 19,575,848,657 9,978,502,174 9,597,346,483
損益 -22,419,468,022 -12,528,948,761 -9,890,519,261
プロフィットファクター 87.31 79.64 97.03
トレード回数 450,404 232,823 217,581
勝率 11.8% 10.38% 13.31%
勝ちトレード数 53,158 24,181 28,977
負けトレード数 397,246 208,642 188,604
最大利益額 1,124,916 942,750 771,349
最大損失額 -210,001 -184,193 -176,186
総手数料額 1,039,870,977 537,521,786 502,349,191
最大ドローダウン -218,535 -186,268 -183,665
２．平均損益・利益・損失額集計
各銘柄でバックテスト（算出）した平均損益額・平均利益額・平均損失額の平均値・最大値・最小値を算出。 通常、各銘柄で算出した場合、平均損益額＝平均利益額＋平均損失額となりますが、全銘柄を集計した場合には数値の性質上イコールにはなりません。 イメージをつかむために全銘柄の平均値・最大値・最小値を算出してみました。 今回のストキャスティクスでの検証の場合、平均損益がプラスとなりました。
[ Fast ]
[ 全トレード ]
AVG ( MAX MIN )
[P/L ] 264 ( 2,638,291 -379,918 )
[PROFIT] 561,998 ( 15,063,360 0 )
[LOST ] -63,698 ( 0 -510,002 )
[ 買いトレード ]
AVG ( MAX MIN )
[P/L ] -8,610 ( 5,281,359 -581,751 )
[PROFIT] 538,156 ( 22,228,684 0 )
[LOST ] -65,882 ( 0 -581,751 )
[ 売りトレード ]
AVG ( MAX MIN )
[P/L ] 12,348 ( 2,432,982 -251,718 )
[PROFIT] 462,822 ( 10,737,711 0 )
[LOST ] -61,161 ( 0 -621,558 )
[ Slow ]
[ 全トレード ]
AVG ( MAX MIN )
[P/L ] -4,015 ( 710,677 -192,044 )
[PROFIT] 365,246 ( 4,685,925 0 )
[LOST ] -56,964 ( -1,209 -661,866 )
[ 買いトレード ]
AVG ( MAX MIN )
[P/L ] -8,584 ( 840,610 -302,775 )
[PROFIT] 394,712 ( 6,618,291 0 )
[LOST ] -58,882 ( 0 -633,840 )
[ 売りトレード ]
AVG ( MAX MIN )
[P/L ] 2,152 ( 1,044,073 -192,985 )
[PROFIT] 317,707 ( 5,027,919 0 )
[LOST ] -54,793 ( 0 -818,503 )
３．平均損益件数集計
こちらも、イメージをつかむため、平均損益がプラスの銘柄・マイナスの銘柄の件数を集計。 やはり、トータル的に観るとマイナスになる銘柄が多いようですが、今までのバックテストに比べるとプラスとなる銘柄が格段に多いです。
[ Fast ]
[TRADE] [+ COUNT] [- COUNT]
[ALL ] 1,088 2,455
[LONG ] 842 2,682
[SHORT] 1,363 2,165
[ Slow ]
[TRADE] [+ COUNT] [- COUNT]
[ALL ] 1,024 2,523
[LONG ] 871 2,669
[SHORT] 1,242 2,296
最終的には今回の検証でも損失が出る結果となりました。
また、バックテストと称していながら、手数料・リスク率・ストップロス・スリッページ・呼び値等を考慮していないものが多数あります。 今回はこれらも考慮しているのでより実際に近いシミュレーションが出来ているのではないでしょうか。 計算間違いしていなければの話ですが・・・ ※計算間違いが発覚すれば、その都度再検証してみるつもりです。
もちろん、実際は場合によってエントリ方法を調整する必要があることは言うまでもありませんが。。。 特にエグジットの条件を変更する（利益のあるうちにエグジットするようにする）ともっと利益に繋がるでしょう。
Ruby 学習の延長で検証作業を行ってみましたが、こうして実際に実用的な何かを作成してみることで知識も深まっていきます。
以上。
Comments