今回はnekoboo FX Core2の検証をお届けします。
v1.01検証中にアップデートがありv1.02となりましたが決定的なバグがあったので
バグ内容の報告をしてからv1.01の結果をお届けします。
nekoboo FX Core2 v1.02のバグ
サマータイム判定を追加されたようですが
そのサマータイム判定がバグってます。
もうね、情けないですよ・・・開発者さんは全くデバッグ確認してないんでしょうね。
新機能の夏GMTが機能してません。
Tickstoryデータ：夏GMT0-冬GMT0
アルパリデータ：夏GMT3-冬GMT2
GMTに変化の無いブローカーならば大きな問題となりませんが
GMT変化のあるブローカーの場合は非常に大きな問題となります。
Tickstoryでも致命的な問題はないですが「成績が落ちる」という問題が確認できます。
nekoboo FX Core2-v1.02-Tickstory-2003.06.02-2015.08.30-スプ20-夏GMT0-冬GMT0
nekoboo FX Core2-v1.02-アルパリ-2000.02.01-2015.01.15-スプ20-夏GMT3-冬GMT2（正常設定）
nekoboo FX Core2-v1.02-アルパリ-2000.02.01-2015.01.15-スプ20-夏GMT2-冬GMT2（わざと異常設定）
夏GMT2、冬GMT2設定の方が成績良くなるとか明らかにおかしいですよね(^_^;)
こういう部分から開発者の開発姿勢や性格が伺えます。
このままじゃfxonのOANDAフォワードにも悪影響があると簡単に推測できます。
もっと真剣に真面目に真摯に開発に取り組んで欲しいと思います。
アルパリバックテスト（v1.01）
v1.01はサマータイム判定が実装されていないので
サマータイムに合わせて取引時間パラメータ変更しなければ正確にバックテストできません。
なので細切れデータを連結してグラフにしています。
またスプレッドフィルターのデフォルトは5です。
実運用する際にスプレッドフィルター5は使い物にならないので20に変更して確認します。
nekoboo FX Core2-アルパリ-2000.02.01-2015.01.15-スプ5
nekoboo FX Core2-アルパリ-2000.02.01-2015.01.15-スプ20
nekoboo FX Core2-アルパリ結果合成値
1年間の運用見込み利益（15年割）＝＄476.81（5.72万円相当）
スプ5最大ドローダウン＝＄375（4.50万円相当）
スプ20最大ドローダウン＝＄500（6.00万円相当）
合成ドローダウン＝＄437.50（5.25万円相当）
リスク対期待値＝1.089
Tickstoryバックテスト（v1.01）
GMT変更の無いブローカーでは取引時間パラメータ変更の必要が無いようです。
nekoboo FX Core2-v1.01-Tickstory-2003.06.02-2015.08.30-スプ5
nekoboo FX Core2-v1.01-Tickstory-2003.06.02-2015.08.30-スプ20
nekoboo FX Core2-Tickstory結果合成値
1年間の運用見込み利益（12年割）＝＄713.27（8.55万円相当）
スプ5最大ドローダウン＝＄334.41（4.01万円相当）
スプ20最大ドローダウン＝＄396.86（4.76万円相当）
合成ドローダウン＝＄365.63（4.38万円相当）
リスク対期待値＝1.952
Tickstory直近バックテスト（v1.01）
nekoboo FX Core2-v1.01-Tickstory-2010.01.01-2015.08.30-スプ5
nekoboo FX Core2-v1.01-Tickstory-2010.01.01-2015.08.30-スプ20
nekoboo FX Core2-Tickstory結果合成値
1年間の運用見込み利益（5.75年割）＝＄579.95（6.95万円相当）
スプ5最大ドローダウン＝＄247.55（2.97万円相当）
スプ20最大ドローダウン＝＄269.17（3.23万円相当）
合成ドローダウン＝＄258.36（3.10万円相当）
リスク対期待値＝2.241
まとめ
ｖ1.01でデータを確認する分には非常に期待できるロジックであることが分かる。
期待できるロジックであるのでユーザーが使いやすくなるよう現時点での問題を列挙します
サマータイム判定バグをはじめ、他にバグは本当に無いですか？
パラメータ設定なども非常に分かりにくくサポート無しにはユーザーは正しく使えない状況です。
パラメータが分かりにくい＝プログラムも複雑になっておりデバッグが難しい状況と推測するからです。
サマータイム判定を導入しているにも関わらず週末エントリー制限がサーバー時間指定になっている。
日本時間指定だったり、サーバー時間指定だったりしてユーザーは混乱します。
日本時間指定ができるなら週末エントリー制限も日本時間指定に統一できるはずです。
そしてサマータイム判定があるので（バグ修正すれば）
営業時間が変わるタイプだろうと、変わらないタイプだろうと問題なく日本時間で利用できるようになるはずです。
一度設定したらロット数以外は2度とパラメータ変更しなくても使えるように設計して欲しいです。
バックテストする際にはtest_modeをtrueにする必要がありますが
これはプログラムで判断できる内容なのでユーザーに操作させる仕様はよくありません。
この設定自体を排除可能です。MQL4を勉強しましょう。
またGMT処理がしっかり行われていればバックテストだろうとリアルだろうと関係なく利用できます。
動作が重いEAです。
これは全ティックで動作するタイプによくあるパターンですが
逆指値の変更が多すぎることが原因と考えます。
1分間に何度も変更していることが確認できます。
皆さんに一度考えて頂きたいことはMT4のヒストリカルデータの最小は1分足です。
その1分足のデータ内容は「4本値と出来高」だけです。
バックテストで全ティック確認しようが最小は1分足です。
「4本値と出来高」だけで1分間にこんなに逆指値変更をできる訳が無いのです。
単にMT4が出来高に合わせてランダムウォークさせていることが推測できます。
よって1分間に1回プログラム動作するように制限するだけで軽くなります。
5分足EAなので5分に1回チェックするというプログラムにするのがベストです。
5分に1回のチェックということであれば「始値」でバックテストしてOKです。
5分に1回チェックするという方法にした場合はどうなるか？
確認する方法は現状のままで始値でバックテストすることです。
nekoboo FX Core2-v1.01-Tickstory-2003.06.02-2015.08.30-スプ5-始値
nekoboo FX Core2-v1.01-Tickstory-2003.06.02-2015.08.30-スプ20-始値
全ティック確認した場合よりも若干良くなる傾向なので
5分足毎に1回動作するだけで十分なことが分かります。
全ティックで動作するEAの弊害はまだあります。
値動き毎にプログラムをチェックするのでCPUに負担が掛かります。
特にCPUの弱いVPSなどを利用している方にとっては大きな問題です。
複数のEAや複数のMT4を運用しているとフリーズする可能性が高くなります。
出来る限りPCに優しい設計にすることが望まれます。
以上が私が感じている問題点です。
これら問題をクリアすれば非常に期待できるEAでは無いか？と思います。
この記事を書いている現時点ではドローダウン傾向にありますが
まだ2ヶ月程度のフォワード実績なので、これからの成績に注目です。
丁寧なデバッグとユーザビリティ向上を期待してます。
今回のようなkawasumi検証記事を自動で受け取りませんか？
