2010年04月01日

新EA開発中 (003)

Alpari・Forex.com のスリッページ(すべり値)はどれ位?

現在EA(吉祥天 Ver0.1)を開発中ですが、どうもうまくいきません。
このEAはマーチンゲールタイプなので複数のポジを同時に決済する事があり、
しかも非常に小さな利益、例えば4ポジの時にトータルで5pipsを決済する時があります。
この時、確実に利益を取っていかないと、危険を冒して4ポジ目まで
保有したにもかかわらず、利益はマイナスなんて事もありえます。
倍々のマーチンゲールタイプなので、最初のポジを0.1Lotとすると2ポジ目は0.2Lot、3ポジ0.4Lot
4ポジ0.8Lotとなります。つまり4ポジ目まで取った場合は
5/(0.1+0.2+0.4+0.8) = 5/1.5 = 0.33/0.1
つまり0.1Lot辺り0.33Pipsの利益となる訳です。

なにが言いたいかと言うと、決済時のスリッページ等が影響して
利益が確保できない可能性もあるという事です。

実際、実験的にリアルで運用してみると、10ドル利益のはずが3ドル
なんて事が平気であります。
そこで、リアルの決済時にどんな事が起こっているかEAを改造して
追跡する事にしました。その結果しだいではEAを利益が確保できる様
に大幅に改造いたします。

実は前から、決済時にどれ位、”すべる”か知りたかったので、丁度良い機会です。
また、結論から言うと、改造いたします。但し、もう少し実験してから


まず、本日のアルパリでの 吉祥天 の取引です。

Alpari(10_04_01_B).BMP
2010年4月1日の吉祥天(Ver0.1) Alpari での取引 @が1ポジ Aが2ポジの取引

少しメタトレーダーの関数の話になりますが、吉祥天は決済に買いの場合は

bOdrClose = OrderClose(iOrderTicket, dOrderLots, Bid, 3, Blue);

と言う関数使っています。簡単に解説すると
iOrderTicketのチケット番号の取引をdOrderLots分
成り行きすなわちBid値で決済し、その時すべり値(=スリッページ)は±3Point
まで許して、チャートの表示はブルーですよ。
結果をbOdrCloseに入れますのでこの結果がTrueならば旨く取引されたし
Falseならば失敗してますよ。
という事になります。

また、一般的に複数のポジションを同時に決済するタイプのEAは決済値に達すると一気に複数ポジションを決済いたします。
これは、一気に決済しないと一部のポジションが残ってしまう事がありその為にアルゴリズムがうまく組めないからです。
私の今までみたタイプの複数決済EAはすべてそうなっています。
(実はこれが利益が確保できない事につながるのですが...)

さて、まず本日(2010年04月01日)の@の取引について見てみます。
取引経歴より買値は 1.35063 である事が分かっています。
また、記録したパラメーターを生で書くと

EURUSD

OrderTime = 17:29:44
ReturnTime = 17:29:46
OrderTicket = XXXXXXXX (変更済み)
RtnOrder = True
OrderBidAsk = 1.35216
Get BidAsk = 1.35216
OrderLots = 0.1(変更済み)

(追記:プログラムを見直して、Get BidAsk は必ずしも正しい値を反映していない事がわかりました。この値は取引経歴からも分かりますので値の確認はしてありますので、話の大筋はかわりませんが、この説明では訂正しておきます。
また、後の説明では RtnOrder = False つまり取引失敗の時にも値を持っていますが、失敗ですので、その時、この値の意味はありません。)


となっています。つまりEURUSDの取引が17:29:44(=Alpariサーバータイム)
に始まり、2秒後にレスポンスがありチケットNoはXXXXXXXX で取引は成功
その時の取引リクエスト値は1.35216 で 実行も1.35216です。
となります。また、この時吉祥天は0.1Lotあたり15pipsの利益を狙っています。
実際は 1.35216 - 1.35063 = 0.00153 (=15.3 pips)となります。
この時、Alpariは非常に優秀(ずるがない?)でスリッページ0で実行されています。

さて、Aの取引について見てみます。
取引履歴よりそれぞれの買値は 1.35264 1.35110 である事が分かっています。また、記録パラメータの生の値を書くと

EURUSD

OrderTime = 01:19:47
ReturnTime = 01:19:48
OrderTicket = XXXXXXXX(変更済み)
RtnOrder = False
OrderBidAsk = 1.35181
Get BidAsk = 1.35181
OrderLots = 0.2(変更済み)

OrderTime = 01:19:48
ReturnTime = 01:19:50
OrderTicket = YYYYYYYY(変更済み)
RtnOrder = False
OrderBidAsk = 1.35181
Get BidAsk = 1.35174
OrderLots = 0.1(変更済み)

OrderTime = 01:19:58
ReturnTime = 01:19:58
OrderTicket = XXXXXXXX(変更済み)
RtnOrder = True
OrderBidAsk = 1.35171
Get BidAsk = 1.35171
OrderLots = 0.2(変更済み)

OrderTime = 01:19:58
ReturnTime = 01:19:58
OrderTicket = YYYYYYYY
RtnOrder = True
OrderBidAsk = 1.35171
Get BidAsk = 1.35171
OrderLots = 0.1(変更済み)

これは一体どういう事かと言うと決済値 1.35181 に達したのだが
実行してみるとサーバーから それじゃ決済させてあげない(=False)
と言われてしまい、2個目の決済の時 1.35174 に成り行きがなってるよと言われて決済できず、しようがないので次の Tick を待っていたら 十秒後の01:19:58に決済できたけど、その時の 成り行き値は
1.35171 に下がっていたって事になります。実行そのものはすりっページなしで実行されており、大変優秀です。
実はこの取引ではトータル 5Pipsを狙っているのですが、まず決済時の
条件を検討して見ましょう。

(1.35181 - 1.35264) + (1.35181 - 1.35110) x 2 = 5.9Pips

で実際に実行された値は

(1.35171 - 1.35264) + (1.35171 - 1.35110) x 2 = 2.9Pips

で、大幅に減っています。これは、実行時に実際の成り行き値が動いて
しまい、(大抵は大勢の人が同時に決済する指標あたりなので利益が減る方向に動く)
減ったと言う事で、この2つの取引に関する限り、

Alpari は スリッページをユーザーの損な方向に動かしていない

という事になります。
(まあ、成り行きが利益が減る方向に動くので同じとも言えますが..)

次に本日の Forex.com(Japan)で実行した結果を載せます。

Forex.com(10_04_01_B).BMP
2010年4月1日の吉祥天(Ver0.1) Forex.com での取引 @が2ポジ Aが3ポジの取引

さすがに、すべて解説いたしませんが、
Bの取引の買値は 1.35107 と 1.35263 また利益 5Pipsを狙いパラメータは
EURUSDpro

OrderTime = 23:32:26
ReturnTime = 23:32:27
OrderTicket = XXXXXXXX
RtnOrder = True
OrderBidAsk = 1.35180
Get BidAsk = 1.35180
OrderLots = 0.2

OrderTime = 23:32:27
ReturnTime = 23:32:29
OrderTicket = YYYYYYYY
RtnOrder = True
OrderBidAsk = 1.35180
Get BidAsk = 1.35180
OrderLots = 0.1

Cの取引の買値は 1.35050 1.35119 1.35259 利益 5Pips パラメータは

EURUSDpro

OrderTime = 05:43:41
ReturnTime = 05:43:42
OrderTicket = XXXXXXXX
RtnOrder = True
OrderBidAsk = 1.35134
Get BidAsk = 1.35134
OrderLots = 0.4

OrderTime = 05:43:42
ReturnTime = 05:43:43
OrderTicket = YYYYYYYY
RtnOrder = True
OrderBidAsk = 1.35134
Get BidAsk = 1.35134
OrderLots = 0.2

OrderTime = 05:43:43
ReturnTime = 05:43:44
OrderTicket = ZZZZZZZZ
RtnOrder = True
OrderBidAsk = 1.35134
Get BidAsk = 1.35129
OrderLots = 0.1

です。注目すべきは最後の

OrderBidAsk = 1.35134
Get BidAsk = 1.35129

でスリッページ以上のスリップですが、後で経歴を見直すと1.35134でした。

少し訳がわかりません。
(追記:取引経歴が正しい様です)

さて、此方は一度もはじかれる事なくたった一回で約定ですが、
チャートの動きもAlpariに比べると遅いので感覚的にもあっています。
利益も確保できた状態です。

Forex.com も スリッページをユーザーの損な方向に動かしたりしていません。

但し、此方はスプレッドがAlpariより広いので、その分最初から損している感じ
です。どちらが良いかは好みですが、少なく吉祥天の決済の方法では
Alpariで利益をすべて確保とは行かない様です。

さて、それでは、利益を確保するにはどうしたら良いのでしょう。
それは、利益確保値以上で決済を実行するEAにする事です。

あれっ 
”複数のポジションを同時に決済するタイプのEAは決済値に達すると一気に複数ポジションを決済いたします。”
って説明しましたよね。一寸、矛盾しますね。

実は、その方がアルゴリズムがやさしいのでそうなっているだけで
複雑なアルゴリズムを考えれば、利益確保型のEAを作る事も可能です。
その為には大幅な改造と実験が必要なので時間が掛かります。
しばらくは今の形で実験を続けます。

追記:きりりさんが教えて下さった方法で改造中です。
   それ程時間が掛からず実現できるかもしれません。
追記2:出来ました。月曜日からテストサーバーで動かしてみます。2010/04/04

posted by 2chの人 at 22:18| Comment(3) | MT4 EAを使おうよ | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
私が取っている手法ですが、保有している全ポジションの合計ロット数分だけ反対ポジションをまず取ります。
これで、決済に必要なプライスに関わるオーダは一回で完了。
あとで、ゆっくり(?)OrderCloseByコマンドで反対ポジションを相殺していけば決済は完了しますw。
OrderCloseByコマンドを使った場合、残っているポジションのTicket番号が変わるのがプログラム作成時の注意点です。
またトレード履歴がとても見づらくなるのがいまいちですね。
ただ残念なことにFXDD,FxProではこの方法使えてますが、FXCM UKではOrderCloseByコマンドをサポートしていないので、ブローカ依存する方法ではあります。ECNブローカはだめっぽいですねぇ。
Posted by きりり at 2010年04月02日 01:50
コメントどうもありがとうございます。
そういう方法があるとは知りませんでした。本日、吉祥天プログラムを見直しながら、その改造ならば比較的簡単な気がしています。まずは改造して動くかどうか確かめてみます。
動いたら、報告しますね。
Posted by 2chの人 at 2010年04月02日 22:34
きりりさんどうもありがとうございます。
さっそく、作ってみました。
割と簡単に作る事ができました。
バックテストでは従来と同じ様な利益が得られます。月曜日からテストサーバーで導入してみます。うまく行けば、再来週あたりから、リアルに導入してみます。
それにしてもトレード経歴はたしかに見ずらいですね。
まあ、利益確保第一なので、この方法が良いですね。
Posted by 2chの人 at 2010年04月04日 01:07
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。