FX自動売買研究記!

    - 為替相場をメタトレーダーの自作自動売買プログラムで勝ち抜く -

    スポンサーサイト 

    上記の広告は1ヶ月以上更新のないブログに表示されています。
    新しい記事を書く事で広告が消せます。

    ( --/--/-- --:-- ) Category スポンサー広告 | トラックバック(-) | コメント(-)

    震災後に相場の波が変わった?? 

    "Ishikawa_USDJPY_30_min"が不調です。
    こいつはドル円の売り専門トレンドフォローシステムなのですが、震災以降下降トレンドにもかかわらず勝てません。
    円高が継続しているので、勝ってくれてもよさそうなのですが、連敗につぐ連敗です。
    もどしが起きやすくなっているということでしょうか??
    震災が影響しているというよりも、介入に対する警戒が結果なのかもしれません。

    下の損益曲線でも、3月からの負けが酷いです。とにかく勝てない。
    確か運用開始が3月からですので、損失しか産んでいません。
    ishikawa_usdjpy_bf
    2001.1.1から最近までの10年間のデータです。

    実運用を開始してから全く勝ててない!!このEAは失敗だった!!!
    と割りきってシステム自体を捨ててしまうのもアリなのかもしれませんが、
    2006年以降は仮想フォワードテストにしているので、たまたま今がドローダウン期であると考えた方が合理的であるはずです。

    まだ信じたい。

    捨てるのは忍びないので、運用しながら気づいた
    “同じような価格で過剰にポジる”
    という欠点を排除して改良をしてみました。

    フィルタ追加後のバックテストはこんな感じ。
    ishikawa_usdjpy_after2

    PFも改善しましたし、3月以降もなんとかなってます。

    しばらくはこの設定で見守っていこうと思います。

    ( 2012/03/06 22:29 ) Category Ishikawa | TB(0) | CM(2)

    約定拒否対策 

    最近約定拒否が多発しています。
    オープンのタイミングを逃すのはまぁ良いとして、イグジットタイミングを逸するのは致命的です。

    約定拒否原因として考えられるのは、
    ①前回処理(ブローカーとの通信)が終了していないためエラーになるケース
    ②相場が激しく動き、設定した価格で取引ができないケース

    の二つだと思います。
    先日、Trade context is busy対策を書きましたが、
    これは①の問題に対する対処法です。

    ここでのメインは、②。
    週明け、指標など、相場の激動によって発生する約定エラー対策です。

    対象となるエラーメッセージはこいつら。

    ERR_OFF_QUOTES 136 Off quotes.
    (ブローカー側で現在の価格を公示が出来ない相場状態なっている。相場が落ち着くまで待つしか無い??)
    ERR_BROKER_BUSY 137 Broker is busy.
    (ブローカービジー。これもエラー136同様、待つしか方法は無い様な感じ。)
    ERR_REQUOTE 138 Requote.
    (激しい価格変化のため、発注しようとした価格が間に合わず公示価格が既に変ってしまった状態)

    これらのエラーは全て、一定の時間を空けて再注文することで対処可能です。


    即ち・・・下記のようにOrderClose()関数を改良して、
    エラー発生時には時間をおいて再オーダーをかけることで対処可能です。

    改良OrderClose()は、SecureOrderClose()としました。

    int SecureOrderClose()
    {
    for(int i=OrdersTotal()-1; i>=0; i--)
    {
    if(OrderSelect(i,SELECT_BY_POS,MODE_TRADES) == false) break;
    if(OrderMagicNumber() != MAGIC || OrderSymbol() !=Symbol()) continue;

    while(true)
    {
    if(IsTradeAllowed() == true) //----①
    {
    RefreshRates();//----②
    if(OrderClose(OrderTicket(),OrderLots(),closeprice,Slippage*10,Gray)==true)
    {
    break;//----③
    }
    }
    Sleep(100); //----④
    }
    }
    }


    ① ここでブローカーとの通信が可能か判定
    ② 実は重要。waitを掛けると価格が過去のものとなるため、ここで再度通貨の価格を取得。
    ③ 正しくクローズが通れば(trueが返れば)、whileを抜ける
    ④ 正しくクローズ出来なければ(falseが返れば)、100ミリ秒待ってやり直し。


    これは例によって市販の解説書を参考としたものですので、詳細に書くのは控えたいと思います。ご了承下さい。

    ( 2011/08/06 19:17 ) Category コード的なこと | TB(0) | CM(0)

    Trade context is busy対策 

    真剣に約定拒否対策に乗り出すにあたり、
    ERR_TRADE_CONTEXT_BUSY 146 Trade context is busy.
    について調べました。

    ■発生理由
    複数EAを同時に運用する場合、EAのオーダー処理の競合が大きな問題になってきます。
    MT4では、複数のオーダーを同時に発注することができないからです。
    そして、その時にエラーメッセージとして表示されるのが
    ERR_TRADE_CONTEXT_BUSY 146 Trade context is busy.
    です。

    MT4上で運用される複数のEAはまるで同時処理されている様に見えますが、
    実際のところ、それぞれのプログラムがきっちり順番に処理されています。
    もし前の順番のEAの処理が残っていれば、次のEAに障害が出るわけです。
    それが最も顕著なのが、注文処理です。
    一つのEAによって発生した注文処理は、メタトレーダーを通してブローカーとのやりとりを行いますが、
    その間に別のEAからオーダーが入ると、後から発注されたオーダーは処理されず、エラーとなってしまうのです。

    それを踏まえて対応を考える必要があります。


    ■対処
    ERR_TRADE_CONTEXT_BUSY 146 Trade context is busy.
    こいつが出ている以上、オーダーは通っていません。
    なぜなら、別のEAの注文によってメタトレーダーとブローカーがやりとりを行っている最中だからですね。
    ゆえに、これを避けるには注文処理が終わるのを待つ以外ありません。

    まずは競合の有無を調べましょう。

    今現在 ERR_TRADE_CONTEXT_BUSY 146 Trade context is busy. が発生するような状態なのか、
    注文の競合が起こる状態なのか。という事を事前にチェックした上で、競合するようならば
    しばらく待機してから発注をかける必要があります。

    このチェックを行う関数が、

    IsTradeAllowed()


    です。
    こいつは、返り値がbool型の関数で、
    今はどんな注文も入ってないからチャンスだよ!って時は、
    IsTradeAllowed()=true
    今は前のオーダーの注文処理中だからエラーんなるよ!って時は、
    IsTradeAllowed()=false
    を返します。

    ここで競合が発生していた場合、待ちをかける必要があります。
    方法は2つ。
    ①EAの処理の中でwaitを入れる方法
    ②オーダが通らなかった場合は再度EAを呼び出す方法
    です。

    対処① EAの処理の中でwaitを入れる方法
    注文が約定するまで、ひたすらwhileループでオーダーをかけ続ける方法です。
    延々と146 Trade context is busy.が出続けるでしょうが、そんなもの何回出ようが知ったことではありません。
    とにかく約定するまで繰り返し続けます。
    注意点は2つ。再注文を出すまで何秒間待機させるかきちんと設定しておくことと、
    無限ループに陥らないよう、ループの脱出に気を使うことです。
    これは
    ERR_OFF_QUOTES 136 Off quotes.
    ERR_BROKER_BUSY 137 Broker is busy.
    ERR_REQUOTE 138 Requote.
    らの約定拒否対策にも使えますので、詳しくは近いうちに書きたいと思います。


    対処② 次のtickまで待たせる方法
    ①に比べると効果は限定的ですが、コード自体はこっちの方が簡単です。

    int start()
    {
    if(IsTradeAllowed() == false) return(0);

    .....
    }

    という感じでメイン関数を呼び出した直後に注文可能であるか判断し、
    このEAの注文を受ける準備ができていなければ、 return(0)によってメイン関数(start())を終了します。
    これだけです。
    MT4の仕様上、次回start()が呼び出されるのは次のtickが更新されたときになるので、
    その時には恐らく注文処理は終了していることでしょう。




    詳しくはこちら。
    http://articles.mql4.com/141
    英語なので大変ですが、
    このエラーの発生理由から様々なケースの対処法とそのコードまでとても詳しく書かれています。

    あ、例によって愛読書にもキッチリ書かれていますよ。
    FXメタトレーダー実践プログラミング (現代の錬金術師シリーズ)
    FXメタトレーダー入門―最先端システムトレードソフト使いこなし術

    ( 2011/08/06 19:01 ) Category コード的なこと | TB(0) | CM(0)

    FXDDの強制決済要件 

    自動売買システムを複利運用するにあたり、強制決済についてきちんと調べてみました。

    実は最近まで、強制決済に対して誤った認識を持っていました。
    “強制決済は有効証拠金がゼロになったときに発生する。”と思っていたのです。
    いやぁ、お恥ずかしい。
    ですから強制決済を食らう直前も、
    「随分含み損があるけど、まだ有効証拠金には余裕がある。反転まで恐らくは耐えられるだろう。」
    なんて思っていました。
    あまりにも無知でした。いやぁ、ホントお恥ずかしい。


    FXDDのHP(必要証拠金とレバレッジの関係について)に、この様な説明があります。

    必要証拠金とは発注した注文に対して担保として最低限必要な額。通称証拠金とも呼ばれます。
    強制決済になる場合は、この必要証拠金が有効証拠金と同じもしくは有効証拠金を上回った瞬間に強制決済となります。


    つまり、保有しているポジションがあまりにも多ければ、
    有効証拠金(含み損益を考慮した残高)が残っていても強制決済の要件を満たすんですね。

    必要証拠金の計算方法によれば、

    必要証拠金の算出方法はこちらです:
    数量 × ドル立てで表記したベース通貨の取引額  ÷  レバレッジ

    例1)
    3ロットのUSD/JPN成行買い注文を200:1口座で発注した場合:
    (当時USD/JPNが85.570)
    3(ロット)x 100,000 (通貨単位)÷200(レバレッジ)=$1500(必要証拠金)
    *注意:USD/JPNの場合、USDがベース通貨(通貨ペアの左にある通過)であるため、数量をレバレッジで割ったでだけで必要証拠金を計算できます。

    例2)
    1.5ロットのEUR/USD成行買い注文を200:1口座で発注した場合:
    (当時EUR/USDが1.3088)
    1.5(ロット)×100,000(通貨単位)×1.3088(ドル建てする為)÷200(レバレッジ)=$981.60(必要証拠金)


    との事です。

    なるほどなぁ。やはり余裕を持った運用をしないとダメですね。

    今回、EAの複利化を行うにあたって
    ◯強制決済の要件(有効証拠金と必要証拠金の関係)
    ◯必要証拠金の計算方法
    を確実に理解しておく必要に迫られたために、こうやって色々調べてみたわけですが・・・

    こんなことも知らずに(強制決済について勘違いをしたままで)FXをやってたなんて、
    今ではちょっと非常識だったかなぁと反省しています・・・


    ( 2011/07/31 15:52 ) Category ブローカーを知る | TB(0) | CM(0)

    生存戦略 

    7/19に記事にしたように、先日証拠金不足により口座が一つ破綻しました。

    複数のEAが同じ通貨を同方向に大量にポジり、それが逆行したからです。
    しかも悪いことに、ヤツら(EA達)は僕が出張中でチェックが甘かったのを良いことに、これを何度も繰り返しました。
    証拠金が少なくなっているのに、懲りずに同じロットで何度もです。

    こんなポートフォリオになっているのですからその危険性には気づいていたのですが、後手に回りすぎました。
    こうなる前に対処しておくべきだったのです。
    もう同じ轍を踏む訳にはいきませんので、これを機に生存戦略を組み込んでいきたいと思います。

              |\__
          {ヽ´     `丶、
         /        __\
             -─-、/   `ヽ
       /  /        ●
       ,′ {   ●   --- 、  /⌒\__
         ⌒\  <r ´ ̄/‐く___,ノ
      { ,、___,> ̄(_厂
     ̄ ̄


    さて、口座の生存を目的として掲げるならば、実現すべきは2点。

    一つ目は、証拠金依存のロット調整。
    資金が少なくなればロットを小さくし、資金が多くなればロットを増やす。
    つまり、EAの複利化ですね。

    二つ目は、“同一通貨を同方向に大量にポジる”という状態の回避。
    適切なポジションサイジングの実現です。
    EAそれぞれのポジションサイジングについては各EA内でしっかり設定をしていたつもりですが、ここで行うべきポジションサイジングとは、システム全体でのポジションサイジングです。

    この二つが生存戦略のキモとなります。
    近いうちに実装したいと思います。

    ( 2011/07/27 22:42 ) Category ポートフォリオ歪みを是正する | TB(0) | CM(0)
    プロフィール

    asahi_fx

    Author:asahi_fx
    日々のEA開発記録を綴っています。

    忙しい時は全然更新できませんが、
    進展がある度に少しづつ書いていこうと思います。



    運用中のEA


    Batou_EURUSD_1h_L
    Batou_AUDUSD_1h_L
    Batou_Counter_EURUSD_1h_L
    Batou_Counter_EURUSD_30min_L
    Ishikawa_EURUSD_1h_L
    Ishikawa_AUDUSD_1h_L
    Ishikawa_EURGBP_30min_L
    Ishikawa_USDJPY_1h_S
    Ishikawa_USDJPY_30min_S
    Togusa_USDJPY_1h_L
    Togusa_USDJPY_1h_S
    Togusa_USDJPY_5min_S
    Togusa_EURCHF_1h_S
    Togusa_EURCHF_5min_S
    Borma_USDJPY_15min
    Borma_EURUSD_15min
    Borma_GBPUSD_15min
    Paz_WPR_gradient_USDJPY_15min
    Pza_heikin_EURUSD_1h



    上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。