ECN、注文執行、アグリゲーター、流動性 - ページ 25

 
sumkin75:
0.1ロットリミッターでストップ高になります。すごいですね。リアルでもそうなのか?
止めるのではなく、改善するのです。止められないんです。スプレッドの中のあなたの指値は、取引所の投機家のようなものです。取引所では、より安定した流動性を得ることができ、より良い価格でボリュームを提供することができます。
 

をランに。

今日、あなたのところでポンドニュースを入力したい人を募集中

12:28:00 '******': instant order buy 0.30 GBPUSD at 1.59821 sl: 0.00000 tp: 0.00000
12:28:00 '******': request was accepted by server
12:28:00 '******': request in process
12:28:01 '******': order buy 0.30 GBPUSD opening at 1.59821 sl: 0.00000 tp: 0.00000 failed [Off quotes]

なぜ「ピーク時取引」に価格がないのですか?もしこれが意図的なものであれば、正直に言ってください。私は資金を引き出し、不必要な注文であなたのサーバーを訓練することはありません。

 
olyakish:

をランに。

今日、あなたからのポンドニュースを入力したかったのです。

なぜ「ピークトレーディング」には価格がないのか?もしこれが意図的なものであれば、正直に話してください。私は資金を引き出し、不必要な注文であなたのサーバーを訓練することはありません。

口座種別がSTPの場合、以下は規則からの抜粋です。

6.4 クライアントがインスタントオーダーの開始時に、要求価格からの最大偏差パラメータを使用する場 合、価格が変更されると、クライアントはオフクォートを受信し、新しいインスタントオーダーを送信する 必要があります。お客様が要求価格から最大偏差パラメータを使用せず、価格が変更された場合、この場合、お客様はRequoteを受け取ることになります。

MTサーバーの技術的な特徴により、この場合、Requoteを送信することができません。

口座がECNなら、おかしいですね。それが何であったかを把握するためには、口座 番号が必要です。

 
Rann:

口座種別がSTPの場合、以下は規定からの抜粋です。

6.4 クライアントがインスタントオーダーの開始時に要求価格からの最大偏差パラメータを使用する場合、価格が変更されると、クライアントはオフクォートを受信し、新しいインスタントオーダーを送信する必要があります。お客様が要求価格から最大偏差パラメータを使用せず、価格が変更された場合、この場合、お客様はRequoteを受け取ることになります。

MTサーバーの技術的な特徴により、この場合、Requoteを送信することができません。

口座がECNなら、おかしいですね。口座 番号がないと、何のことかわからない。

了解です、ありがとうございます、すみません、STPアカウントです。
 
olyakish:
了解です、ありがとうございます、すみません、STPアカウントです。
サーバーログには、オフクオータがリダイレクトとして表示されます。前回ECNサーバーのリダイレクトがあったのは9月でした。
 
MetaDriver:
一般的にはこのような感じです。
https://www.mql5.com/ru/forum/12342/page3#comment_543724
このような事態に対応するためのTCロジックという観点からも興味深い。

テイクで指値注文があった。

- リミットラインは何度か部分的に約定し、テイクラインと合わせて複数のオープンポジションを発生させました。同時に、残りのボリュームはLimitの形で残りました。

- それぞれのポジションは、テイクによって部分的に閉じられた。

そのようなことがあってもロジックを崩さないようにTSを書くにはどうしたらよいのでしょうか。

一度、解決策を声に出した

すべてのアルゴトレーダーは、テスター用ロボットを実際の市場で動作するように戦闘状態に変換する作業に直面しています。
実は、正しい訳し方はひとつしかないのです。幸いなことに、それはほぼ全世界共通です。

戦闘ロボットはテスターとシンクロナイザーの2つの部分に分かれています。

テスターでは、テスターロボットの歴史上の瞬間(現在に至るまで)の取引環境を提供します。
シンクロナイザーは、このデータを現在の実際の取引環境と照合し、(テスターで得られた)仮想の取引環境と適合させようとするものである。

例えば、仮想環境では、あるレベルにリミッターが存在することがわかります。この価格帯でこのようなリミッターを実際のマーケットで作ることがシンクロの仕事である。

これまでアルゴリズムトレーダーは、ロボットの両方のパートを書かなければなりませんでした。最初の部分であるリアルタイムテスターの執筆を引き継ぐことを提案します。

つまり、リアルタイムに履歴を補充し、テスターロボットの実行を(止めずに)継続するテスターである。この場合、このテスターの現在の仮想取引環境を取得するためのあらゆるメカニズムが存在する。
このような標準的な実装があれば、アルゴトレーダーが戦闘的な取引ロボットを書く際に大きな助けとなるだろう。残念ながら、私が知っているアルゴリズム取引ツールには、このような機能はありません。

追伸:ユニバーサルシンクロナイザーはありえません。しかし、同期には、根本的に異なる2つのアプローチしかないのです。

  1. クラシック-スルーマーキー(現行より悪い価格でラリマー)。これは最もシンプルな方式で、マーキーを通じて取引環境をコピーするものです。この方法の長所は、フルリピートと視認性の良さです。デメリットは、ネガティブスリッページです。つまり、数学的な期待値が低いTSには向かないのです。
  2. 指値注文で。例えば、取引されたBUYがコピーされたポジションの始値でBuyLimitとみなされる場合。コピーされているすべての指値注文も考慮されます。この方法の利点は、負のスリッページを中和できることです。マイナス点は、指値注文のリダイレクトで結果が歪んでしまうことです。

この古典的な方式は、現在普及しているすべてのシグナルサービスに何らかの形で実装されています。この方式は、シンクロナイザーが非常にシンプルで、クライアントの取引コストを気にしないため、サービス側にとって有利である。

2つ目の方式は、私の知る限り、どこにも使われていない。おそらく、本当に迷惑なアルゴトレーダーが実装しているのでしょう...。

私は、開発者が両方のタイプのシンクロナイザーを社内で書くことを提案します。そもそもアルゴトレーダーに必要なのは、これら全てです。なぜなら、このツールバイシクルの発明や調整に労力を費やすことなく、戦闘的な市場環境に対応したロボットを素早く書くことができるようになるからです。

 
Rann:
止めるのではなく、改善するだけなのです。彼らはそれを止めることはできない。スプレッドの中のあなたの指値は、取引所の投機家のようなものです。取引所はより多くの流動性を与え、より良い価格で量を提供することができます。

ははは、まさにストップ高。もちろん、永遠にではありません。一方、コチラは、与えられたカップの外側に移動することができます。デモ参加者が少ないからと言って、世界の価格がデモ参加者に依存するわけではありません。

大きな金額でデモを開設してみてはいかがでしょうか。スプレッドの内側に2つのカウンターリミットを開き、それぞれ100ロットとしてください。5本の棒は確実に平らになります。

でも、プラスアルファがあるんです。買わなくても、売らなくても、見積もりは動くことを知りました。リミットの価格を変えるだけでいいんです。一部は削除され、新しいものが置かれるかもしれません。

 
sumkin75:

しかし、そこには明るい兆しがあります。買わなくても、売らなくても、見積もりは 動くということに気づきました。限度額の価格を変更するだけでいいのです。一部は削除され、新しいものが置かれるかもしれません。

)
 
sanyooooook:
)
何がおかしいのか、悲しい。本物のパッツァトレーダーの 多くは、価格は売買によって変化すると考えている。
 
sumkin75:

買わなくても、売らなくても、見積もりは動くということに気づきました。限度額の価格を変更するだけでいいのです。一部は削除して新しいものを入れることができます。

はい、外部のサプライヤーからスプレッド内に移動することは可能です。