成行注文を正しく発注するにはどうしたらよいですか？ - ページ 8

新しいコメント
 
Dmitry Fedoseev:
間が悪いのはあなたです。
まさにそれです。
 
とにかく、イマドキの底辺はこうだ。

世界的には2通りあります。

1）環境の分析（取引履歴の吸い上げ、オープンポジションやポジションの出来高の確認）。

2）トランザクションの分析

1は動作が遅い。でも、そのほうが信頼性は高い。妥協点が必要だ。おそらく、戦略を見て、それに依存する必要があるのでしょう。

そう、FORTSには本格的なティッカーがあるので、ティックではなく、 BookEvent イベントで動作させる必要があるのです。

Vasily Sokolovが この件に関してコメントしないのは不思議だ。彼の視点は面白い...
 
Dennis Kirichenko:
とにかく、イマドキの底辺はこうだ。

世界的には、2つの方法があります。

1）環境の分析（取引履歴の吸い上げ、オープンポジションやポジションの出来高の確認）。

2）トランザクションの分析

1は動作が遅い。でも、そのほうが信頼性は高い。妥協点が必要だ。おそらく、戦略を見て、それに依存する必要があるのでしょう。

そう、FORTSには本格的なティッカーがあるので、ティックではなく、 BookEvent イベントで動作させる必要があるのです。

Vasily Sokolovが この件に関してコメントしないのは不思議だ。彼の視点は面白い...
近いうちにガラスに変えるかもしれませんが、今は......昔ながらの方法で。
 
Dennis Kirichenko:
とにかく、イマドキの底辺はこうだ。

世界的には、2つの方法があります。

1）環境の分析（取引履歴の吸い上げ、オープンポジションやポジションの出来高の確認）。

2）トランザクションの分析

1は動作が遅い。でも、そのほうが信頼性は高い。妥協点が必要だ。おそらく、戦略を見て、それに依存する必要があるのでしょう。

そう、FORTSには本格的なティッカーがあるので、ティックではなく、 BookEvent イベントで動作させる必要があるのです。

Vasily Sokolovが この件に関してコメントしないのは不思議だ。彼の視点は面白い...
ところで、質問があるのですが、BookEvent イベントをTickやTimerと同じように使うことはできるのでしょうか？
つまり、自分の戦略をそこに完全に移せるかどうか？
 
この話題で思い出したのですが...

私はかつてこの注文を 担当し、CiOnTradeクラスを書きました。
class CiOnTrade : public CTrade
面白い仕事だった。私とクライアントはお互いにイライラしてしまい、心が折れてしまいました。私の記憶では、保証された数量を売買するのが主な仕事だったと思います。また、一部の数量が埋まらなかった場合は、その注文を削除して、残りを別の価格で売らなければならない......。

そこで、私が見つけた最適解は、状態の処理にありました。そして、その数はとても多かった。
enum ENUM_TRADE_STATE
  {
   TRADE_STATE_NONE=0,      // "ничего"
   TRADE_STATE_ORDERS=1,    // "только ордера"
   TRADE_STATE_POSITION=2,  // "только позиция"
   TRADE_STATE_ALL=3,       // "все"
  };
1) "Nothing"-何もしていない初期状態です。

2) "注文のみ" - 注文が入った時の状態です。

3) 「ポジションのみ」とは、注文が完全に執行された状態です。

4) "All "は、注文が完全に約定していない状態で、すでにポジションがある場合です。

そのため、各州ごとに処理する必要がありました。はい、ちなみに中間状態もあることは認めています。だから、私のクラスは改善される可能性があります。
 
Gennady Mazur:

つまり、自分のストラテジーを完全にそこに移行することができるのでしょうか。
はい、しかしBookEventはより頻繁にイベントを生成することに注意してください。だからこそ、不要なものをふるい落とすフィルターが必要なのです。例えば、価格は変わっていないのに、一部の入札の数量だけが変わっている...。
 
Dennis Kirichenko:
はい！しかし、グラスの方がイベントが発生しやすいとお考えください。そのため、不要なものをふるい落とすフィルターが必要です。例えば、価格は変わっていないのに、一部の入札の数量だけが変わっているなど...。
ありがとうございます。特に強いレベルの近くでは、価格の変化よりも出来高の変化の 方が重要なケースがあります。
 
Dennis Kirichenko:
要は、イマドキはこうなんです。グローバルでは、 1）環境分析（取引履歴を吸い上げ、オープンポジションやポジション量を確認する）、 2）取引分析、の2つの方法がある。







1は動作が遅い。でも、そのほうが信頼性は高い。妥協点があるはずだ。おそらく、私たちは戦略を見つめ、それに頼らざるを得ないのでしょう。
OrderSend+Sleep(0) のバリエーションは OrderSend+OnTradeTransaction よりも遅く動作しない。測ってみました。したがって、私は、非同期トランザクションのためではなく、2番目のバリアントを使用しません。
 
Dennis Kirichenko:
取引に関する情報はまだ来ていないのでしょう。ここ（赤で 示した部分）は、運に頼ることになる。そして、彼女は気まぐれな女性なのです :-))

bool OpenSellPosition(string symbol, double volume, string comment="", ulong deviation=10, ENUM_ORDER_TYPE_FILLING filling=ORDER_FILLING_FOK)
{
  MqlTradeRequest Request;
  MqlTradeResult Results;
  ZeroMemory(Request);
  ZeroMemory(Results);
  Request.price=SymbolInfoDouble(_Symbol,SYMBOL_BID);
  Request.action=TRADE_ACTION_DEAL;
  Request.type=ORDER_TYPE_SELL;
  Request.symbol=symbol;
  Request.volume=volume;      
  Request.deviation=deviation;
  Request.comment=comment;  
  Request.type_filling=filling;
  bool res=false;
  res=OrderSend(Request,Results);
  if(res)
  {
    if(Results.deal>0) return(true);
    else return(false);
  }
  return(false);
}

ORDER_STATE_FILLEDでも、Results.orderに問題がある場合がある - Results.dealが0になる。この状況をFXOpen-MT5サーバーで100%再現しています。

私は、異なるサーバー上で多くのデモを開き、コードの完全な機能を達成することをお勧めします。MT4 biblicalのためにそうしました。だから、サブゲームに問題はないのです。

 
fxsaber:
OrderSend+Sleep(0) は OrderSend+OnTradeTransaction よりも遅くはないです。測ってみました。したがって、私は2番目のバリアントは非同期トランザクションのためではなく、使用しません。

OrderSend+Sleep(0) のバリエーションは開発者の 欠点なので一時的なものです（例として使わないでください :) ）。

修正されると、OrderSendだけが残ります

123456789
新しいコメント
理由: