FX自動売買研究記!

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

    最強のインジケーター 

    僕がFXを初めて間もない頃、色んな本やインターネットの情報を読みあさっていました。
    そこで気に止まったのが、

    『信頼出来るインジケータは、先を読めるインジケータでは無い。
     使用する人間が多いインジケータである。』

    という言葉です。
    これは、そもそもインジケータは相場を予測するものではなく、特定のインジケータに則って売買する人間が多い場合、結果としてそのインジケータが相場の動きを作り得るんだよ。
    という意味なんですが、
    この言葉、インジケータの存在意義を見失うほどの物凄い逆転の発想ですよね。
    インジケータを多用して未来を予想しようと躍起になっていた僕にとって、これは目からウロコでした。


    では、使用する人間が最も多いインジケータは何でしょうか。
    移動平均線クロス、RSI、MACD、一目均衡表etc....
    売買のトリガーになりうる指標は数多くありますが、これらは全て違います。
    例えば、
    『短期移動平均線を6期間、長期移動平均線を12期間で取るのが理想です。
     私はこれで連勝しています。ホラこれが売買記録です。確かに勝てているでしょう?』
    と主張する人が居たとしましょう。
    一見説得力がありますが、この主張は移動平均線の優秀さを証明するものではありません。
    ここには単に、その期間においては6期間と12期間のクロスで勝てた人がいる。という事実があるだけで、他の期間を用いた移動平均線ユーザーは負けているかもしれないのです。
    勝てた人の声は得てして大きく響くものであり、その声の大きさが移動平均線はインジケータとして優秀だと錯覚させているにすぎません。その他の指標も、概ね同様です。

    言い方を変えれば、
    移動平均線やRSI、MACDなどは、使用する足、参照する期間が固定されていないため、大多数の人間が“統一的”に使用するインジケーターには成り得ず、真の意味では“使用する人間が多いインジケータ”になり得ないのです。

    さて、
    それをふまえて僕の考える最強のインジケータは、トレンドラインです。
    トレンドラインは変数を持たないからです。
    まてまて!あんなもの引く人によってラインがまちまちじゃないか!
    と思われるかもれませんが、ちょっと思い返して下さい。

    時々、トレンドラインがとても引き易そうなチャートが発生することがありますよね。
    その場合のトレンドラインは、高い確率でユニークに定まり、
    そして間違いなく、強い抵抗線の役割を果たしているハズです。

    こんな風に。
    trendline
    (2010.9.10 EURUSD1時間足)

    トレンド継続期間はおよそ一ヶ月間。けっこう大きめのトレンドです。
    見ての通り、しっかりとトレンドラインが抵抗線として機能しています。
    この様なトレンドラインの働きは、様々な通貨ペアで、至る所で目に出来ると思います。
    そして、この強固なトレンドラインがトレーダー心理に影響を及ぼし、さらにこのトレンドを強化するのです。
    トレンドラインという指標が相場を形成しているとも考えられますよね。


    そいういったわけで、トレンドラインは間違いなく優秀な指標です。
    しかしながら、これは人の感想に依存した、とてもファジーな指標であると言えます。
    定量的にしか物を測れないプログラム上でどの様に再現していけばよいのか・・・


    様々な方法を試しましたが、最近になってようやく形が出来てきました。
    また近いうちに記事にしたいと思います。

    ( 2012/06/05 22:40 ) Category 自作インジケータ | TB(1) | CM(1)

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

    "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)
    プロフィール

    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