数十万行の四本値

  • 1銘柄あたり数十万行の四本値を利用してのバックテスト方法を解説します。

メモリ不足

Excel 2007, 2010(32bit)

Excel 2007, 2010(32bit)では、利用出来るメモリは最大2GBのため、膨大なデータを取り扱うとリソース不足・メモリ不足が発生しやすくなります。PCに搭載してあるメモリが4GBでも、そのうち利用できるメモリが2GBのため、実際のメモリを増やしても効果は無いようです。

四本値のCSVファイルを分割することで、メモリ不足を回避できます。

Excel 2010(64bit)

Excel 2010(64bit)では、利用出来るメモリは最大8TB(8000GB)のため、メモリ不足はPCに搭載するメモリを増やすことで回避できるでしょう。この場合でも、ファイル分割によるバックテストは、再計算の速度を向上させるのに効果があるでしょう。

バックテスト例

  1. 1分足の225先物の四本値が25万行のデータを対象にします。

    20120728fig1.png

    10.5MBのファイルです。

  2. これを3分割して3つのファイルにします。
    例えば、8万・8万・9万行のCSVファイルにします。

    20120728fig2.png

    デイトレードでのシステムなら、日付が変更になる行で分割すると良いでしょう。
    例えば、89,933・80,062・80,005の合計25万行でも構いません。

  3. 最も行数の多いファイルを貼り付けた後、[サイン配置・シグナル作成]を実行します。

    9万行が最大なら9万行に合わせます。

  4. 銘柄セットに3ファイルを配置し、バックテストを行います。

    日付は、225FU_a.csvの最初の日付より前にしておけば良いです。

    20120728fig3.png

バックテスト結果

  • システムは225先物ラージ1分足を利用した単純な買いのみのシステムです。
  • 極めて頻繁にシグナルが発生します。
  • 実際の運用ではスリッページのためシステム上の価格では売買できません。
  • しかし、単純なルールでかなり良い成績になったのは意外でした。システム構築のヒントにはなりそうです。

2011/07/19 ~ 2011/11/11

最初のファイル、225FU_a.csv単体でのバックテスト

2011/11/11 ~ 2012/03/08

2番目のファイル、225FU_b.csv単体でのバックテスト

2012/03/09 ~ 2012/07/20

3番目のファイル、225FU_c.csv単体でのバックテスト

2011/07/19 ~ 2012/07/20

3ファイルを銘柄セットに配置してのバックテスト

  • 225先物なので、\10 は 1万円となります。
    従って、損益は、26,020なので、2602万円となります。
  • 買い負け数が多いのは、引き分けも負け数と換算するからです。
  • 期間 2011/07/19 ~ 2012/07/20

買いに対して

  • 買い勝ち数 6622
  • 買い負け数 12299
  • 買い取引回数 18921
  • 買い勝率 35.00%
  • 買い利益 \74,640
  • 買い損失 -\48,620
  • 買い損益 \26,020
  • 買いP/F 1.54
  • 買いPOR 2.85
  • 買い利益額平均値 \11
  • 買い利益額中央値 \10
  • 買い損失額平均値 -\4
  • 買い損失額中央値 \0
  • 買い損益額平均値 \1
  • 買い損益額中央値 \0
  • 買い 勝ち最大保有期間 4日 06:01
  • 買い 勝ち最小保有期間 0日 00:01
  • 買い 負け最大保有期間 4日 06:08
  • 買い 負け最小保有期間 0日 00:01
  • 買い 最大保有期間 4日 06:08
  • 買い 最小保有期間 0日 00:01
  • 1トレード 買い最大利益額 \220
  • 1トレード 買い最大損失額 -\220
  • 買い最大到達利益額 \26,140
  • 買い最大ドローダウン -\590
  • 買い標準偏差 10.43
  • 買いシャープレシオ 0.1319

制限

四本値を複数のファイルに分割するバックテストには、次のような制限が発生します。
1番目と2番目とのファイルの四本値を連続してシグナル算出に取り扱うことはできないためです。

  1. 1番目のファイルの終わりがけにあるデータのシグナルはExitされない可能性があります。この段階でEntryされたシグナルは本来2番目以降のファイルの四本値でExitされるはずですが、それは算出できません。
    同様に、2番目以降のファイルでも同様です。

  2. 2番目のファイルの始めあたりにあるデータのシグナルはEntryされない可能性があります。この段階でEntryさせるシグナルは本来1番目のファイルの四本値を利用して算出されるはずですが、それが利用できないためです。
    同様に、3番目以降のファイルでも同様です。

  3. 2番目のファイルの始めあたりで算出されたシグナルは、1番目のファイルのデータを利用しないものになります。
    同様に、3番目以降のファイルでも同様です。

  4. MACDなどのようなテクニカルの算出方法が、その前にある全てのデータの影響を受けるタイプの場合、2番目・3番目・・・のファイルでのテクニカルの値は本来算出されるべき値とは異なります。ただし、これは、誤差の範囲として無視できるレベルでしょう。

意図しないシグナルになる可能性を抑える方法

かなり技術的で細かい事柄です。また、これを理解し実行しても、さほどシステムの成績の向上に見合うものでは無いと判断しますが、一応、記載しておきます。

制限の1番目

デイトレードのシステムなら、日付が変更になる行で分割することで、本来発生すべきExitが発生しない問題を回避できます。

制限の2, 3番目

ファイルの終わりがけのデータを次のファイルの始めで重複して利用します。

  1. ワークシート上で、貼り付けた四本値の最初100行分ではシグナルを発生させないようにします。
  2. 1番目のファイルの終わり100行と、2番目のファイルの始め100行を同じ日付・時刻の四本値にします。
  3. 2番目・3番目以降のファイルでも同様にします。

これらの方法の必要性

これらの方法を実行する必要性はそれほどあると思えません。それは、次の理由によります。

  • 数十万行の四本値で頻繁にシグナルが発生するシステムなら、数カ所の意図しないシグナルが発生してもそれほど影響が出ないでしょう。もしその数カ所のシグナルが大きな影響を持つなら、そのシステムは過剰最適化の罠に陥っていると判断できます。

  • 日足を利用してのシステムなら、数カ所の意図しないシグナルが大きな影響を持つでしょう。この場合、出来る限り正確なシグナルを算出する労力をかけても良いかもしれません。ただし、8万行を利用するなら、80,000日÷365日=219年分ですから、四本値のファイルを分割して利用することは無いでしょう。