こんばんは。

最近のリアル取引の履歴を見ていて、「んん？」と感じることがあったので書こうと思います。

下の画像を見てください。

これは、今朝のFXCM-UKでの当サイト配布の無料EA、Clab_EURGBPによるEURGBPの取引結果です。

エントリー②はよろしいのですが、エントリー①がengineeeer的によろしくありません。

engineeeerが期待するエントリーは③辺りになります。

これはスリップを広くしているからではありません。

今日だけではありません。最近良く遭遇します。研究員の皆さんもこの経験をしているのではないでしょうか？

では、なぜとても乖離とは思えないこの①の場所でエントリーしてしまっているのでしょう？

原因はプログラムにあります。でもバグではないです。

このEAを開発するにあたって、以前から申していますように、

同手法の他EA（FAPTURBOやM16など）に負けないというのが絶対の目標でした。

その中で、重要なポイントの一つにここが関係していました。

プログラムのお話になるのでちょっと専門的な言葉が出てくるかもしれないので難しく読みにくくなってしまったらゴメンナサイ。なるべく気をつけて書きます。

EAはTickが更新されるたびに呼び出されます。（これはインジケータも同じです）　そして、時間計算や指標などのチェック、決済エンジンのチェック、既存オーダーのチェックなどを行い、だいぶ後のほうで注文を計ります。これが通常だと思います。

engineeeerは、このような単純な流れではなくちょっと変えていまして、オーダーが入る可能性が高いとき意外は余計なルーチンを呼び出さないようにしています。他の処理のときもそうです。長い関数の結果で判断するようなプログラムを作ると動作が重くなります。Tickが更新された後、EAのstart()関数が終了するまで次のTickは受け付けません。状況に応じて必要な関数だけが呼び出されるようにプログラムすることが高速化・トレードの効率化を図る上で求められます。（未だにあまり褒めてもらえませんが、バックテストの高速化もここが関係しています。他EAと大分差があると思うのですがねｗ）

そして、EA内部でオーダーを出すときの注文価格は、通常Tick更新時の価格を利用することになります。

ここです。うまくスリム化してオーダーを出す関数までたどり着くのですが、それでもやはりTick更新時との時間差があります。よって、オーダーの判断を指標で行った後、そのまま価格データを使用しても、既にブローカーのサーバー側では価格が更新されてしまい価格差が生まれ、オーダーが通らないことになってしまいます。その許容をSlippageに入力してオーダーを出すのですね。
他のEAでは、Slippgageオーバーで約定拒否がかなり起きていました。また、それによって約定拒否を防ぐ対策としてSlippageを10倍？だのと不思議なサポートやレビューが某有名EAでありました^^;

そこでengineeeerは、注文直前に価格データを取り直そうと考えました。そうすれば約定拒否が少しは改善するかなと。それには、　RefreshRates()　という関数を使用します。この関数は、価格データを更新（リフレッシュ）してくれます。

しかし、この関数をオーダー関数前に記述することは半分ナンセンスなことでもあるのです。指標などでオーダーを出すかどうかを計算した価格データとは違う価格をオーダーで使用することになるからです。

そこでengineeeerはリアルで検証をしました。

オーダーに該当する乖離があった場合にその価格がどれくらいの時間有効なことが多いのかを。

その結果、注文直前に　RefreshRates()　を記述したほうが成績が良いということになりました。検証には当時から使用していますFXCM-NYとFXDDを使いました。

ところが、最近様子が変わってきているように思います。画像のようなオーダーを最近良く目にするようになりました。（engineeeerの所持口座の中では、特にAlpariが多いです。FXCM-NYでは未だにほとんど見られません。Alpariのリアル取引結果が他ブローカーと比べて悪い？事もこれが原因していると思われます。）

勝手な推測ですが、

ブローカーが、オーダーできないくらい長短時間の髭を意図的に作り出しているのかもしれません。乖離したときの価格の保持時間があまりにも短すぎるのです。スプレッドが小さいブローカーではこのような巧みなコントロールをしているのでしょうね。

ブローカーもあの手この手と対策を打ってきます。engineeeerも負けてはいられませんｗ　どんどんこちらもバージョンアップを計ります。

この違いは、バックテストでは分かりません。バックテストではstart()関数が終了するまで価格データが更新されないからです。さらには、バックテストではTickデータは勝手に生成されます。どのような計算式なのか知りたいですね。何度テストをしても同じTickの動きになります。

オーダー直前に価格データをリフレッシュするかどうかのパラメータを次バージョンアップで出そうと思います。お楽しみに。

今日でアンケート回答は締め切りです。今週末、集計するのが楽しみです。こちらもお楽しみに！

＜＜新規認定研究員＞＞

投機小僧さん、masakiさん、shinさん、burikiさん、kapiさん、taatanさん、

以上の６名を当サイトの研究員として認定致します。よろしくお願いいたします。

こんばんは。

ようやく今週はEAラボウィークです。アセンブラの頭をCに戻して悠々と頑張ります。

来週半ばにアンケートの集計および一部公開を致しますが、パラ～っと眺めていて思うことと最近FORUMを見ていて思うことがあり、気になったので書きます。

EAラボラトリーの研究員募集では初心者さんにどんどん参加してもらうように働きかけをしています。それは初心者さんの意見・検証というのがとても重要ではないかと考えたからです。私のようにFXに半分入り浸りの人間は単純・純粋に物事を考えられなくなっている可能性がありまして、その失われていくフレッシュさとでもいいましょうか、そういうものを補う意味でも、また、MetaTraderでEAによる自動売買を行う人たちの流れというのを感じるためにも熟練者だけでEAの検証などを行っていくことは正当ではないと思っています。

そんな大切なMetaTrader初心者研究員さんのために、トレードにおいて基礎となるプロフィットファクター（PF）の考え方を書こうと思います。FXトレードを始めてまもなく、MetaTraderでの自動売買に手を付けた方が結構いらっしゃるようなので、ストラテジーテスターの結果を見て感想を述べるだけではなく、PFの計算をきちんと覚えてパラメータの設定の参考にしていただければと思います。この計算がわかっていない人は、カーブフィッティングを起こしやすくなるはずです。以前カーブフィッティングという言葉をブログで使いましたが、実感がわかなかった方もいらっしゃるのではないでしょうか？「そんなの知ってるやい！」って思う方も確認の上でも是非最後まで読んでください。

プロフィットファクター（PF）　＝　総利益 / 総損失

です。これは簡単ですね。得にEAの世界ではPFは２以上あると優秀と言われています。では問題です。

リミットが4pipでストップが32pipで必ずどちらかで決済するトレードの場合、PFが２になるようにするには勝率は何％必要でしょうか？

答えは約９４％です。

きちんと求められますか？limitを変化させてPFが２になるような勝率を求めると以下の表になります。

PFを２出すには勝率が94%ないといけないことになります。また、「limitを２～６あたりでは勝率が90%以上あれば勝てるトレードなんだなあ？」という感じのことは読み取れますでしょうか？

ではちょっと見方を変えて、勝率94%で各limitでのPFはどうなるかを見て見るとこうなります。

どうですか？limitを１減らしただけで、同じ勝率でトレードを考えたらPFは1.5足らずになってしまうのです。
そして２以下では負けになってしまいます。

もうお気づきの方もいらっしゃると思いますが、ｌimit=4,stop=32　というのは、Clab_EURGBPのデフォルト設定です。
このEAの対象通貨ペアである、EURGBPとEURCHFはスプレッドが非常に重要です。毎日チャートを眺めていれば limit=4というのがどうなのかいろいろ考察できると思います。

また、EAラボラトリーのEAにはTPが２種類あります。VirtualTPとHiddenTPですね。特にClab_EURGBPは、一瞬の乖離を狙うEAですのでエントリー後のTP方向への戻りもまた一瞬です。そして大きいのが普通です。表現が間違っていると思いますが、勢い余ってTP以上のprofitが望める場合も少なくありません。そんなときのために２種類あります。

以前も書きましたが、HiddenTPは注文時にLimitを打つものであります。そして、VirtualTPはTick毎に監視して決済を図るものであります。ブローカーに合わせて是非有効活用して下さい。
engineeeerのTP設定は多くがVirtualTP=3,HiddenTP=5です。

このようにPFの計算をきちんと頭に入れておくことで、バックテストもきちんと行えますし、テスターを走らせ無くても目処がたちますので、検証の時間短縮にもなります。あまり重要視してい方がいらっしゃいましたら参考にして下さい。

今朝FORUMで、これに関連するような書き込みがたろー研究員によってありました。
www.ea-labo.com/support/viewtopic.php
 

いい考察だと私は思います。面白いことにengineeeerのリアル使用でのSLも50にしてあります。いろいろ試して見るべきですね。そのときも当然パラメータを変化させる意味というのをよく考えて弄ってください。ただ、PFをあげることはただのカーブフィッティングになってしまいます。フォワードテストでは無意味になります。
 

また、「50はちょっと大きいな～」と思う方。engineeeerと同じですね。そういう心理が邪魔をする裁量判断は大DDや塵が積もって気づけばもったいないDDを生みます。バックテスト結果に忠実にパラメータをセットしてあとはEAに全て任せます。そうすることが出来るようになってから負け組から脱出することが出来ました。いまではもう全く裁量をトレードをする気がおきません。

今回はPFを題材に取り上げました。
EAの公開パラメータは全体のごく一部のパラメータですが、トレードにおいて基礎でありいろいろと検証する必要があると思います。是非いろいろな視点での考察をお待ちいたしております。

こんばんは。いや、おはようございます。

最近はホントに忙しくて、EAタイムに入る時間がこんなに遅くなってしまいます＞＜。睡眠3時間くらいです＞＜。

そんな中でも、研究員の皆様が頑張って検証をしていることや、バージョンアップを楽しみにしていること等のうれしい応援メールをたくさん頂き少しでもと頑張っています。

さて今日は、最近値動きが得意なパターンであり、スプレッドが低く安定してきていますEURCHFですが、この通貨ペアに先日対応させましたClab_EURGBPの最適化を図ってみましたので経過を追って書こうと思います。普通のことをしているだけだと思いますがengineeeerがどうやって最適化をしているのか参考にしてみてください。非公開パラメータの調整も含まれますので一部わかりやすく伏せさせていただきます。

とりあえず、今回の最適化の目的は、
トレード回数を倍くらいに増やしたい
ということです。

私は多次元のOptimize（複数個所のパラメータ変化の組合せによる最適化調査）はあまり行いません。理由は、時間がかかること、Optimizeパラメータの設定ミスを途中でなかなか発見できないこと（終ってから「あっ＞＜。この2時間はいったい・・・・。」みたいなことによくなるから）、それぞれのレポート内容が細かく見れないこと、各パラメータ独自での効果・変化を見落としがちになることです。このミスは、カーブフィッティングに繋がります。でも一番の理由は、考えながら楽しんで最適化を行いたいからです。OptimizationがOnでは、グラフが出ません。見ててつまらないです。

（カーブフィッティング…短いスパン（少ない要素数）で好成績を確認できるようなパラメータの最適化。短いスパンで好成績だっただけで、長いスパン（十分な要素数）で見るとその最適化が逆効果だったりする。しかし、どれくらいのスパンを短すぎと判断するかはトレーダーによって実にさまざまなため見解の相違が見られる。EAの調整でもっとも大事なところでもある。by engineeeer）

ということも踏まえてですが、あまり時間も無かったので、今回は以下のような段階でテストしてみました。

トレード回数を増やすためには、フィルターの緩和の手などもありますが、今回はエントリーに関わる内部の非公開パラメータの一つの調整で行いました。乖離の尺度を一部を下げてみるって事ですね。それに伴い、TP（target/hidden）を合わせこんで、Trades（トレード回数）、PF（プロフィットファクター）、損益(Profit)、勝率（won）、の4つの結果で比較していきます。以前に記事で書いた、ドローダウンですが、SecretCutter2と他損切りエンジンに任せていますので、この程度の調整ではあまり気にしていません。

最適化以外のパラメータですが、
現時点のバージョンClab_EURGBP 5.1.0 Betaでのデフォルトパラメータから調整したのは、
トレード時間（20-23）、MaxTrades（6）、SecretCutter2（true）だけです。

Metatraderテスト環境は、
FXCM-NY　Real（生データ）　2009/3/23~2009/7/25　スプレッド5固定（2桁ブローカー表記）　0.1ロット固定　EveryTickです。

まず、デフォルトでのバックテスト。

以前、スプレッドは7で固定してのテストだったので、スプレッドの差分2pipsは多く取れるだろうということで、そのテスト。

ちょっと、勝率が落ちますが、Profitが20%以上も増加しているので現行バージョンではTP=6/7がよさそうですね。それを踏まえて、乖離パラメータを弄ります。TPも感でずらしてますｗ。

勝率は前回とあまり変わっていませんが、PFが落ちています。VirtualTPでの決済が行われていない可能性があります。そこでTPを下げてみます。

もっとPFが悪くなってしまいました。

乖離ではないところでエントリーしてしまっているということですね。ここで、default&TP5/6はどうなのか気になったので、そのテストをしました。

PF・勝率両方とも、先の二つのdefaultチェックの間になっていますので、乖離レベル判定はdefaultでおおよそベターのようです。でも悔しいので、間を取って・・・

一気に、勝率が落ちてしまいました。乖離レベルの判断はやはりdefaultがいいみたいです。
それでも悔しくて、じゃあ今度は逆にもっと乖離レベルを甘くしたら？ってことで、

お？トレード回数が2割も増えたのに、勝率はあまり変わらない。ならばここでTP前後に変化させて、２パターン調べてみる。

TP4/5では乖離レベル-1とあまり変わりませんね。また、TP6/7ではProfitはこの中で最大ですが、勝率は70%台に突入してしまっています。defaultから40%も取引が多くなっているのに、利益は25%しか増えていません。そしてこの勝率かぁ・・・。

という具合です。まあ、たったこれだけ？という方も多いとは思いますが、初心者の方にも最適化というのを見比べて欲しかったので書きました。

この段階で考察できることは、
取引回数を増やして多少の利益増は臨めるが、リスクも増すのでお好みで。ということになりますかね。（engineeeerの金銭感覚ですが）　しかし、他のパラメータも含めての調整でプラス方向へ傾かせることができそうだという期待と課題も残されています。研究員の皆様自身でも検証できるように、いつかこの乖離レベルのパラメータの一部を公開するようにしたいと思います。
また以前にも申し上げましたが、人によって期待したり楽しいと感じるトレード回数や勝率は違います。defaultはあくまでengineeeerの環境でのお好みセッティングの一つですので、研究員の皆様個人でお好きな形に変えるといいと思います。楽しいシステムトレードにすることは継続するために必要だと思います。

また、PFと勝率が比例して動かないことから、EURCHF通貨ペアで特徴的な、一瞬の髭を捕まえることが一番有効なのだということが窺えます。EURGBPと同じ手法のようですがこのテストをすると明らかに経過が違います。なので、非公開パラメータ部分はEURGBPと全然違います。何かを何倍したとかいう調整だけでは他のEAと変わらなかったのでそのような単純な事はしていません。

どうでしょう？EAなら、いやMetatraderなら通貨ペアの特徴というものも、こうして目で見て理解することができます。

度理系なengineeeerはこうしてわざわざ数値を出して考察することでしか特徴を見出すことしかできないかもしれません。感覚でモノを言われると、「もしかしたら・・・」と疑ってしまいます。所詮バックテストなのでしょうけども、理屈があるのでこの方が納得できます。そんなことも今回言いたかったのです。
でもきっと、文型の方からこんなことしなくてもぱっとチャートを見ただけで通貨ペアの特徴なんかがかなりの精度で考察できるのでしょうね。文型の方の能力恐るべしですね。
文系理系の問題じゃないのかな？ただの考えすぎか、慎重すぎるのか、理屈っぽさの問題かもしれませんね。

世の中のすべては０と１で表すことができると唱えたシャノン様に一歩ずつ近づいているのなら嬉しい限りです。どうぞ夢の中で大きくうなずいて下さいませｗ。

うぅ完全に朝だ。。。

昨日、GoldSpider_USDJPYを配布いたしました。EAの内容については数日後に書こうと思います。

次に配布しようとしてますのは、おなじみユロポンスキャルピングEA

【Clab_EURGBP】

です。この系統のEAは有名なものにFAPTURBOがあります。またYour_LuckyやThunder4WD、M16A4などもこれにあたります。今となってはスプレッドがきつきつですのでブローカーの癖にあわせてうまくパラメータを調整しないと勝てませんよね。engineeeerがこれを開発したのが数ヶ月前になりますが、その時点ではスプレッド５でのバックテストで例に上げたEAをどれをも突き離していました。なかなか稼いでくれているEAです。
現時点でもリアル運用はしていますが（今日はエントリーありませんでした）、公開にあたってここ最近の相場でのバックテストを行ってみました。
最近はなかなか渋いですね。やはりどんどん稼げなくなっていっているみたいです。持ち味だったパラメータを調整してPF3.0は出せましたが、あと付けですからね。何とでも出来てしまいます。この先どうなるでしょうかね。engineeeerはFXCM-NYでトレードしています。FXCM-UKはなぜか変動が小さいです。サポートセンターに電話して聞いて見たのですが、「そんなことは無い！」の一点張り。証拠撮って送ってくれって言ってます。みんなで送り付けましょかｗ

バックテスト結果、2009/06/01-2009/07/07 （別窓表示）（FXCM-NY,Spread=3.2固定,単利0.1ロット）

プログラムに詳しい方ならわかると思いますが、わざとバックテストを重たく作っている場合もあるはずです。（技術・知識不足で重たくなっているのが多いでしょうけどね。）　バックテストは高速でないとengineeeerは嫌です。そのために何行もプログラムを付け足して日々最適化に励んでいます。
 

先ほど、engineeeer的には微妙ですが、GoldSpider_EURJPY が1勝しました。
たまには自慢画像を掲載してみます。

エントリーが微妙ですが、決済はうまいことやってくれて良かったです。

順次配布していく予定ですのでお待ち下さいね。

Strategy Tester Report（ストラテジーテスターレポート）日本語訳すると、運用試験報告。

今回はバックテスト結果であるこのストラテジーテスターレポートの見方と、それを利用した効率の良いEAのOptimize（オプティマイズ）最適化について書こうと思います。間違った解釈をしている方が多いですのできちんと抑えておきましょう。また、ここを頭に入れておくことで使えるEAと使えないEAの区別ができるようになっていただければ幸いです。ネット上で安全に使えるEAというのはなかなかお目にかかれませんよ。

これは今開発検証中の、Monkeyシリーズのポン円Verのあるテスト結果です。パラメータはすべて削除してあります。注文ロットは固定で0.1ロットです。
まずは各項目の説明です。

1. Bars in test ･･･ テストをしたBarの数
2. Tick modeled ･･･ テストで使用したティック数
3. Modelling quality ･･･ テストで利用したティックの割合
4. Mismatched charts errors ･･･ 試験時間足と測定に使用に使用した時間足データとの相違数
5. Initial deposit ･･･ 初期準備額
6. Total net profit ･･･ 総純損益（純利益－純損失）
7. Gross profit ･･･ 純利益
8. Gross loss ･･･ 純損失
9. Profit factor ･･･ プロフィットファクター（総利益／総損失）
10. Expected payoff ･･･ １トレード当たりの期待損益（総純損益／総トレード数）
11. Absolute drawdown ･･･ 初期投資額からのドローダウン
12. Maximal drawdown ･･･ 最大ドローダウン（最大金額）
13. Relative drawdown ･･･ 相対ドローダウン（最大比率）
14. Total trades ･･･ 総トレード数
15. Short positions (won %) ･･･ 売りトレード数（勝率）
16. Long positions (won %) ･･･ 買いトレード数（勝率）
17. Profit trades (% of total) ･･･ 勝ちトレード数（率）
18. Loss trades (% of total) ･･･ 負けトレード数（率）
19. Largest profit trade ･･･ １トレード当たりの最大利益
20. Largest loss trade ･･･ １トレード当たりの最大損失
21. Average profit trade ･･･ 勝ちトレードの平均利益
22. Average loss trade ･･･ 負けトレードの平均損失
23. Maximum consecutive wins ･･･ 最大連続勝ちトレード数（利益）
24. Maximal consecutive losses ･･･ 最大連続負けトレード数（損失）
25. Maximal consecutive profit ･･･ 最大連続利益（勝ちトレード数）
26. Maximal consecutive loss ･･･ 最大連続損失（負けトレード数）
27. Average consecutive wins ･･･ 平均連続勝ちトレード数
28. Average consecutive loss ･･･ 平均連続負けトレード数

のようになります。とても便利ですよね。

さてここで、このテスト結果のいくつかのパラメータに注目して、EAの最適化をしていくことを考えます。
あくまで、engineeeerのやり方でもありますがまあ見て下さい。基本的に重要であるのが、

9.  Profit factor ･･･ プロフィットファクター（総利益／総損失）
12.  Maximal drawdown ･･･ 最大ドローダウン（最大金額）
13.  Relative drawdown ･･･ 相対ドローダウン（最大比率）
14.  Total trades ･･･ 総トレード数

になります。目標の目安ですが、

Profit factor は、一般的に2.0以上あれば優秀であると言われています。engineeeerもそう思います。というか、3.0やそれ以上のPFをたたき出すEAにはろくなものなありませんし、ろくな結末がありません。この辺は後で説明します。

Maximal drawdown と Relative drawdownですが、これが一番大事です。かつ、皆さんとらえ違えているところだと思います。説明します、
前者はレポート画像の①の場所にあたります。後者は②の場所にあたります。どちらも山の頂上から谷の最下点以下までの金額差になります。
ここで今、最下点以下と書きました。そうです、その通りなんです。グラフを見ると青と緑の折れ線グラフがあるのが分かりますね？青はBalance（口座残高）、緑はEquity（純資産）を表します。こう書くとわかりにくいですが、

Balance（青）は、オーダーを出しても減りません、そしてオーダーが決済されて始めて増減されます。
Equity（緑）は、オーダー時にブローカーに預ける証拠金分がすぐ引かれます、そして当然オーダーが決済されるとロスカットで無い限りもちろん証拠金は口座に戻ってきますのでその分元に戻ります。

金額差と書いたのもこの辺を分かってもらうためにあえてあいまいな言葉を使いました。
ということは･･･、私たちが最悪の事態を想定して考えなければならない、余剰証拠金の推移がグラフに出ていないのです！

テスターレポートの金額差（ドローダウン）は、余剰証拠金の高低の金額差です。

そして、なぜ Maximal drawdown と Relative drawdown が違うドローダウンの場所になっているかです。ここも捉え違えている人が多いです。金額と割合を入れ替えただけとか言っている人もいます。違いますよ^^;　これは、金額と割合のどちらに注目しているかで取り扱うポイントが違うからです。
 

Relative drawdown は、テスト期間中に起きたドローダウンの中で、上記の割合が最大になったときのドローダウンの割合を算出しています。その括弧内の金額は、そのドローダウン額です。

グラフの横軸は決済したオーダーの順番です。その最中に他にいくつのオーダーがあって、それらがどれだけ損失を抱えているかはグラフからは分かりません。しかし、グラフには出ていなくても、数値としては Maximal drawdown と Relative drawdown として算出されているのです。EA視点で言いますと、よくあるナンピンをフル活用してマネーマネジメントしているEA（ナンピンは使い方を間違わなければ効果バツグンです。数学的に考えての話です。）は、ストラテジーのグラフで見るときれいな右肩上がりの一直線を出します。でも実際の口座内の動きは恐ろしいものです。そんなときこのRelative drawdown をチェックしてください。

もう一度話を戻します。

上の画像での、
Maximal drawdown （①）　4684.64(12.90%) は、
最大ドローダウン額＝4684.64＄
最大ドローダウン額／ドローダウンが起きる前の口座残高×１００＝最大ドローダウン率（％）　ですので、
4,684.64／36,315.04×100=12.90%　となります。

Relative drawdown （②）　27.86％（2876.39）は、
ドローダウン額＝2876.39＄
ドローダウン額／ドローダウンが起きる前の口座残高×１００＝ドローダウン率（％）　ですので、
2876.39／10324.44×100=27.86%　となります。（初期投資額より324.44＄多いのは、一瞬プラス損益が出たからでしょう。）

このデータから推測しなければならないことは、このテストの注文ロットは固定で0.1ロットですので、グラフのどの位置の事象もどこでも起き得ると考えなければなりません。ですので、
最大ドローダウンがもし、EAスタート直後に起きたらどうなるかを考えなければなりません。テストの期間を①の直前からに設定してテストしてみると分かります。Relative drawdown 50% になります。スタートしていきなり口座資金が半分になります。

また、Maximal drawdown と Relative drawdown の両方が小さい数値を出しいてる場合は、初期投資額を見てみてください。グラフの縦軸の最下段は0ではありません。ストラテジーの結果で自動調節されています。
どうでしょう？　50000＄とかになっていませんか？500万円ですよ？大金スタートですねぇ。それならドローダウンの値が小さくなるのは当然です。

ここまで来て初めて、投資計画を考えます。そのままのEAのパラメータで取引を行うなら、テストから算出される最大ドローダウンの十倍くらいの資金を用意しましょう。でなければ、パラメータを変更して、最大ドローダウンが小さくなるようにしましょう。小さくならなければそのEAはあなたに適していません。破産する前にしかも1銭も市場にお金をさらさずに判明してよかったですね。（有料EAならEA購入代金分は損しちゃいますけどね）

次に、総トレード数ですね。

これはですね、2つの点から考えます。
投資心理面　と　統計学的見解　です。

PFもDDもバッチリだけど、取引は1回／月程度･･･　ってどうですか？
engineeeerはイヤです。両方の見方からです。月一回の取引のために、PCを24時間フル稼働ですか？なら、ここぞとばかしの指標発表時にスキャルを一回やったほうがいいのではないでしょうか？投資という枠から外れるような気がします。でももっと納得がいかないのは、統計学的見解からのことです。
1回／月ってことは、過去5年のバックテストを行っても、60回の取引データしかないことになります。たった60回のバックテストによる統計を信じる気ですか・・・。

というわけで、engineeeerの作るEAも最低でも月20回は取引できるようにしています。なら平均１日１回は取引を見れるでしょう？

これらをTotalで見て、もう一度PF（プロフィットファクター）を考えます。すると、不思議ですね～。やっぱり年間ベースでPF3.0を超えたりすることはなかなかないです。engineeeerがまだ未熟で作れていないだけかもしれません。作れている人がいたら是非教えてください。ｗ（教えてくれるわけはないでしょうがねｗ）

そして、仮に偶然ではなく作れたりしたとします。そのようなものは、engineeeerは攻略法的EAだと思っていますので、誰かに知られれば、すぐさま連鎖的に広がっていきます。そしてなんらかの対策が打たれ終焉を迎えます。最近のユロポンのようにですね。
そう、出る杭は打たれるんです。私も本職でそんな経験をいっぱいしてきました。
この研究所発のEAが将来出たとしたら、努力した私たち研究員だけで使っていきたいですね。そうできるように、アルゴリズムがばれたりしないようengineeeerは頑張ります。

Maximal drawdown は、テスト期間中に起きたドローダウンで最大の金額差になったところを指し、その金額を算出してます。その括弧内の割合は、そのドローダウンが起きる直前の余剰証拠金の最大額を100％としたときのドローダウンの割合です。

engineeeerは裁量スイングトレードが下手です。結果なんて無残なものです。

でも、原因はわかっています。損切りではありません。損切りは意外と簡単にできちゃいました。原因は逆の利食いですね。目標リミットを設定しておきながらいざ予測どおりの方向に動くと途中で逃げちゃいます。そのトレードでは勝ちは勝ちです。しかし、そう、あらかじめ計算しておいたプロフィットファクターの計算を完全に無視していることになります。

プロフィットファクター（PF）＝勝ち額／負け額

EAのカテゴリで詳しく説明しますが、EAの研究開発では特にこのPFとあと最大ドローダウンに注意していきます。

 勝率とPFの計算に基づいてリミットとストップを打ちますので、このバランスを勝手に崩すことはPFの計算そのものを無視していることになります。

この無意味な逃げを防ぐには、自分の中では未だチャートを見ないことしか対処方法がありませんｗ　でも見ていないと、他通貨のエントリーチャンスを逃す可能性もありますし、第一同じPCで仕事していることが多いのでそれは難しい課題です。

ここで言いたいことは、まあengineeeerだけかも知れませんが、トレードを完全自動でEAにやらせるようになったら、逃げも無くなったってことです。engineeeerは自分の作ったEAを99%信じていますからｗ。EAは電力さえ食べさせれば永久に自分の代わりになってくれます。

そんな人きっと多いはず。少なくともここの研究所に顔出す人はそういう人が多いと思いますね。