EAのプロフィットファクタを上げる簡単な方法(プログラミング要)

EA
スポンサーリンク

EAを自作した際、『もう少しプロフィットファクタあげられないかな』と思ったりしませんか?

今回は、私が自作しているEAを修正してプロフィットファクタの底上げを行いました。2021年に新規運用したEAですが調子がいまいちだった(微利益で1年終わっちゃった)ので2022年版に改良しました。

その際行ったプロフィットファクタの上げ方について記載していこうと思います。

トレード内容を振り返る

まず、どうすればもっとプロフィットファクタや利益が上がるかを確認していきます。それはもちろんトレード内容の改善なのですが、それが難しい。

とりあえず去年のEAのトレード結果を見て、何が悪かったのか等をざっくりでいいので洗い出していきましょう。

私の場合は、

①決済ポイント及びトレールポイントが悪い
②あまり有効でなさそうな場所でエントリーする時がある

この2点が大きな問題でした。この問題にフォーカスしてソース修正をしていきます。

ただ、これだけでは漠然とし過ぎていてどこを修正したらいいのかわからん!

ということで、どうしたらいいのか次に記載していきます。

バックテストでBADトレードを確認する

どこのソースを修正していくかですが、オススメはバックテストのビジュアルモードを使って実際に悪いトレードを探します。

普段からトレード結果を見ている場合は、その問題があったトレードの期間をバックテストしてもいいですし、ざっくり去年からとかでバックテストを始めてもいいのでとにかく悪いトレードを見つけ出します。

見つけ出したらバックテストを止めて日付をしっかり覚えます。上記の画像はショートで2回エントリーしていますが、このトレードは修正の余地があるなと思いました。

ソースコードの修正

①決済位置を見直す

まず、1回目のトレードですがエントリー部分はいいのですが決済部分はもう少し待っても良いのかなと思いました。

決済ポイントは直前のZigZagの安値(黄色い水平線部分)を下に更新できなかったと判断して、決済してしまっています。ここのトレードを見て思う事はもう少し決済するのを様子見したいという事です。こんな感じ。

修正前は水色の部分で決済してしまっていましたが、修正を加えた事で修正前よりは良い位置で決済するようになりました。修正内容は以下です。

直近の安値を更新できなかったら決済 ⇒ 
     直近の安値を更新できなかったら直近の高値付近にストップロスを置く

このようにソース修正しました。

よって、最後の黄色の部分でストップロスに引っかかって決済されています。
※最後の黄色丸の左側に小さく黄色「-」があるのがストップロスです

ストップロスをもっとシビアに置くと逆にプロフィットファクタが悪くなった(変な場所で狩られる事が増えた)のである程度余裕を持たせました。

②いらないエントリーを省く

次に2つめのエントリー部分ですが、これは下げた後の戻りをショートでエントリーしています。が、戻りの割合が直近の下げに対して大きすぎるという風に思いました。

直近の高値と安値でフィボナッチを引いて確認しても61.8%以上戻しちゃってるので、こういう戻しが大きい場合(61.8%等)は以下のように修正しました。

戻しは大きくても直近のZigZagのTOP値を超えていなければエントリー ⇒
  戻しが60%以上の場合はエントリーしない

◎私がソース公開しているZigZagのEAでいうとこんな感じの修正です
if((ZigTop[1] – ZigBottom[0]) * 0.6 < (Bid – ZigBottom[0])){
    orderPtn=0;
}

このようにソース修正しました。

よって、ここではエントリーしなくなりす。

修正箇所の確認

ソース修正をして以下のようになっている事が確認できればソースコードの修正は完了です。

修正すると当然他のトレードにも影響してくるので他のトレードもビジュアルモードで確認します。

・安値を切り上げた場合、 直近の高値付近にストップロスを置くいていること
・ 戻しが60%以上の場合はエントリーしないこと

これが確認できたらOKです。ソース修正が完了したら終わり!

ではなく、次の作業が大事です。

バックテストで総合的に良くなったかを確認する

ソース修正をした事で先ほどの部分のトレードが良くなっていても、他の部分で致命的に悪くなっている事も結構(かなり)あります。

結局先ほどの修正が良かったのか悪かったのかは長期的なバックテストの結果を持って判断します。ここでのバックテストはビジュアルモードでは確認せず結果のみで確認します。

修正前

修正前のプロフィットファクタは1.45で総取引数は3286回でした。結果でよく見る部分を赤枠で囲っています。

修正後

修正後のプロフィットファクタは1.63で総取引数は2875回でした。総取引数は400回近く減っているのに純益が増えているので1回あたりのトレードの質が上がっている(期待利得が上がっている)事がわかります。勝率は2%程下がりましたがこれは仕方ない(質の悪い勝ちトレードが減った)ことなのでOKです。

一番下のグラフをみても2020年~2021年にかけて修正前は横一直線だったのが右肩上がりに変わっています。

修正前と修正後で明らかに修正後の成績が落ちた場合

今回のようにトレードの1部分をみて良い感じにトレードするように修正しても、全体のバックテストであまり良くならない、むしろ悪化することも結構な割合であります。

ということは、直近の安値を更新でいなければさっさと決済したほうが良かったのかもしれないですし、7割戻していてもエントリーしていた方がよかったのかもしれません。

修正を1つづつ行いどの修正が有効性が高いのかを確認していく必要があります。

修正内容を見直し(6割戻しを5割戻しにして見るなど)をしていきますが、いくら修正しても全然成績がよくならない場合は今回の修正内容は適用しないという判断をする場合もあります。

私も上記の修正をすると成績があがったので記事にしていますが、他の修正も当然したりしていて成績が悪化したのも結構あったのでその修正は戻したりしています。

過去の値動きに特化しすぎた修正をしていないか確認する

ビジュアルモードでトレードを見ていると、あのトレードも直したいこのトレードも直したいってなってきます。悪いトレードを直すのは良い事なんですが問題が1つあります。

カーブフィッティング(曲線あてはめ)です。

カーブフィッティングを行うと当然プロフィットファクタは良くなります。既にあるデータに対して良くなるような超限定的な修正になってしまうからです。

あれ?この修正はカーブフィッティングっぽいなって思った場合の簡単なオススメ確認法は、『別通貨でバックテストしてみる』です。私の場合、今回のEAは米ドル/円で運用するものですがポンド/円でも確認しました。

修正前

修正後

修正後の方が成績が良くなっているので、純粋にトレードの質が向上したという事がわかります。

さいごに

以上が、『EAのプロフィットファクタを上げる簡単な方法』です。

EAの修正の仕方は個人で結構ばらばらだと思いますが、私の場合はこんな感じで修正していっています。有効そうな修正内容とバックテストでの確認を含めるとこれだけでも30時間はかかったと思います。ただ、微妙なトレードの改善は必要だと思いますので定期的にやるのが良いと思います。

2022年はこの修正したEAで勝負していきたいと思います!

 

 

※ EAのサンプルソースを一覧表にまとめました


※ オススメ記事(EAが使える国内FX業者の一覧)


※ 1からEAの作り方を学びたい人はこちら

コメント

  1. poko より:

    はじめまして。どの記事もとてもわかりやすくて大いに参考にさせてもらっています。
    本記事の決済位置修正について質問があります。
    「直近の安値を更新できなかったら直近の高値付近にストップロスを置く」の「直近の安値」と「直近の高値」は、チャートでのZigZagの頂点なのでしょうか?(パラメーターSL_Gosaの分、余裕を持たせている?)
    もし可能でしたら、修正部分のソースを教えていただけると大変ありがたいです。

    • りょう りょう より:

      はじめまして、pokoさん。
      記事を見て頂き有難うございます!

      「直近の安値」と「直近の高値」についてですが、「直近のZigZagの安値」と「直近のローソク足の高値」という感じです。(自分で見直しても?でした、すみません)

      修正ソースについてですが、私のサイトで公開しているソースでは決済部分を作りこんでいないので参考になるかどうかわからないですが一応お伝えします。

      //売りエントリー中に、ZigZagのZigBottomが切り上げたら決済する
      if(OrderType() == OP_SELL && ZigBottom[0] > ZigBottom[1] && orderPtn !=2){
      if(BottomPoint == 0 && ZigAtai3 != 0 && ZigAtai2 == 0 && ZigAtai1 == 0 && rosokuValueCloseP > MA_BASE){
      //OrderKekka = funcOrder_Close(20,MagicNumber,clrMediumSpringGreen);
      OrderKekka = funcOrder_Modify(Bid + 60 * Point,OrderTakeProfit(),MagicNumber);
      }
      }
      【サンプルにない各変数、関数の説明】
      ZigAtai3、ZigAtai2、ZigAtai1は、ZigZagの安値が確定してから2ローソク足分でその安値を更新できなかった場合って感じで使ってます。ZigZagの安値が確定してから、次のローソク足でそのZigZagの安値を更新するとそれが最新のZigZag安値になるのでその場合は決済したくないためです。(要は下げ止まった場合に決済したくて、下げ続けている場合は決済したくない)
      あとrosokuValueCloseP はローソク足のクローズ値、MA_BASEは15分足の21EMAです。

      funcOrder_Close()関数は決済注文、funcOrder_Modify()関数は変更注文として自作の関数です。

      • poko より:

        早々のご丁寧なお返事ありがとうございます!

        ただ、記事中の画像での黄色「-」が出ているバーは、ZigBottomが切り下がっていて、さらにZigZagの安値が確定してから1ローソク足分のように思えるのですが、なにか勘違いでしょうか…

        それと、条件にMAも使っているんですね。
        試してみたところ、当該のバーで「クローズ値>15分足の21EMA」とならないのですが、これもなにか間違っているのでしょうか。以下のようにしています。
        rosokuValueCloseP = Close[1];
        MA_BASE = iMA(NULL, 0, 21, 0, MODE_EMA, PRICE_CLOSE, 1);

        続けざまに細かいところをすみませんが、お返事いただけたら幸いです。

        • りょう りょう より:

          なるほど、よく見られている・・・!

          ZigBottomが切り下げ確定したタイミングで、1つ前のZigBottom前後(パラメータのSL_Gosa_S分)にSL設定する処理は元々いれていたのですが、記事の画像の通り切り下げる前に決済されてしまっていたので今回の直近のローソク足の高値にSL設定する処理を追加しました。この処理を入れた事で元々いれていた1つ前のZigBottom前後にSL設定する処理が実行された形になります。

          MAの件は同じ日時で確認されたという事でしょうか?
          MAの値が違うからでしょうか。私はEMA(13)で見てました。

          double MA_BASE = iMA(NULL, 0, 13, 0, MODE_EMA, PRICE_CLOSE, 1);
          double rosokuValueCloseP = iClose(NULL, 0, 1);

          • poko より:

            なるほど、そういう処理が元々あったのですね、わかりました。
            トレールのやり方にも、色々考えようがあるんですね。

            聞いてみたいことは尽きないのですが、お手をわずらわせるのも申し訳ないので自分で色々試してみます。ご解説ありがとうございました!

          • りょう りょう より:

            はーい。もし何か分からない事があれば、問合せフォームからご質問頂ければわかる範囲で回答いたします。

            https://fx-prog.com/contact/

タイトルとURLをコピーしました