MT5でポジションの集計構造のRELIABLEな会計を実装することは可能でしょうか？ - ページ 21 1...141516171819202122232425262728...33 新しいコメント kombat 2009.10.16 21:46 #201 Figar0 >> : 何度も言うようですが、なぜなんでしょう？また、MT4とはどう違うのですか？ どうやらMT4では、ストップはポジションと注文ごとに設定されているようです。 しかし、5では、数学的なロックを実現するために、保留中の注文をストップとして配置する必要があります。 初期トレードのストップが「ロス」になってしまうから・・・。 ストップ: s-l と / または t-p など SZZ：間違っているかもしれない というのも、私はまだこの会計の話についていけてないので...。 削除済み 2009.10.16 21:50 #202 kombat писал(а)>> どうやらMt4では、ストップはポジションごと 、注文ごとに独立して 設定されていたようです。 しかし、5では、例えば数学的なロックを実現するために、ストップとなる間を置く必要があるのです。 初期トレードのストップが「ロス」になってしまうから・・・。 停止：s-lと/またはt-pということですね。 それはわかったけど、なんで削除できないの？2つの保留中の注文を設定し、それらのチケットを記憶し、シンプルなブロックがそれらの可用性を監視し、1つがトリガーされると2つ目が削除される、要するにすべてはMT4と同じです...。 kombat 2009.10.16 21:57 #203 Figar0 >> : 買ったのに、なぜ削除できないの？2つの注文を保留し、そのチケットを記憶し、シンプルなブロックがその可用性を監視し、1つがトリガーされると2つ目が削除される、要するに、すべてがMT4のようになる...ということです。 なぜなら、実際のカウントは「突然」不具合が出るわけではないので、確実に削除する必要があるからです。 との関連で、このテロップを消すには何というか、どのテロップを消せばいいのか...。 とにかく、こんな感じで...。 しかも、そのコンプはオンラインでなければならないことは言うまでもありません。>>ずっとです。>>わかりやすくするため。 Mykola Demko 2009.10.16 22:01 #204 Figar0 >> : 買ったのに、なぜ削除できないの？2つの注文を保留し、そのチケットを記憶し、シンプルなブロックがその可用性を監視し、1つがトリガーされると2つ目が削除される、要するにすべてがMT4のようになる......ということです。 つまり、オフラインで保留中の注文が1つ発動すると、2つ目の注文がぶら下がったままになってしまうのです。 削除済み 2009.10.16 22:21 #205 Urain >> : オフラインで1つの保留注文をトリガーすると、2つ目の保留注文はそこに留まるということです。 これは当然のことです。しかし、取引サーバーとの接続が完璧な場合のことも意味しています。MT5がマーケットターミナルであれば、指値注文はデプスチャートに理想的に配置でき、ストップ注文はマーケットオーダーとしてMetaTrader5 Execution server自体で実行されます。トレードサーバーに完璧に接続した状態で説明しています。 - ストップ注文は、現在保有中のポジションのStopLossとして設定されます。 - 現在保有中のポジションのTakeProfitとして、指値注文（ウィンドウ内）が設定されます。 - 重要なニュースが流れると、価格はストップオーダーに到達し、すぐに（1秒もかからずに）リミットオーダーに殺到する。(これらの命令が互いに近接している場合、この状況は非常に一般的です)。 その数ミリ秒の間に何が起こるのか。 - 執行サーバは、市場価格で逆指値注文を執行するための成行注文を送信します。 - 執行サーバーは、ストップオーダーが執行される価格を受信し、トレーダーに送信します。 - 執行サーバーは、指値注文が執行されたという通知を受け取り (MetaTrader5 の執行サーバーではなく ECN または取引所がその執行に責任を負う)、その情報をトレーダに送信します。 面白いのは、最後と最後のポイントが違う順番になることです。 そのため、両方の注文が実行され、トレーダーは、取引サーバーと完全に接続されている場合、Stop注文がトリガーされた後にLimit注文を削除することができませんでした。 追伸：この例は、指値注文を市場に出さず、成行注文として執行サーバーで執行する場合にも有効です。 P.P.S. 一般に、どうしても削除が間に合わないという状況があります。そこで、前述したFILL->KILLのオーダーの相互関係が有効である。 Vladimir Klepinin 2009.10.16 23:49 #206 ああ！まあ、つまり、一方がトリガーされると、他方は自動的に市場や市場から削除されるキャンセル可能な注文を作るために追加の可能性を作るために開発者に提案がある？ 削除済み 2009.10.17 08:04 #207 MetaTrader4でのネット取引方法を CodeBaseで提案し、仮想ポジションの目的と実装について洞察を与える。 TheCore 2009.10.17 08:42 #208 getch >> : MetaTrader4でネット取引を行う方法を CodeBaseで提案し、バーチャルポジションの目的と実装のアイデアを提供しました。 アルパリのホームページでMQが言っていたことを思い出してみよう。 MetaTrader5では、取引部分には全く異なるアーキテクチャを採用しており、ポジションを別々に持つという考え方とは真逆のものになっています。同一システムで、個別と複合のポジション保有を組み合わせることは技術的に不可能である。。 まだ1週間も経っていないのに、getchがMT4でネット取引を行うエレガントな 方法を提案しているのが分かる。 それ以外の場合は、から始まります。- "長い間考え、専門家に相談し..." ただ、自分がミスをして、最後まで考えず 、当然の ように四半期ボーナスをもらったことを認めるのは、人間にとって非常につらい ことです。 Hide 2009.10.17 08:47 #209 getch >> : MetaTrader4でネット取引を行う方法を CodeBaseで提案し、バーチャルポジションの目的と実装のアイデアを提供しました。 自分でも訂正します。 1.なぜ必要なのか？ 2.一度に複数のポーズをとらないというシンプルな方法は適切ではないのでしょうか？ 3.何を証明するのか？ kombat 2009.10.17 09:01 #210 thecore >> : アルパリのホームページでMQが言っていたことを思い出してください。 まだ1週間も経っていないのに、getch さんがMT4でネット取引をするエレガントな 方法を提案されているのがわかります。 2006年当時、同じMQがネッティング・トレーダーに対して、同じようにエレガントに提案した。 https://www.mql5.com/ru/forum/54564 2006年当時、この指標は配信に含まれているのですが...。 ネッティング業者がこれを使わないのは、一般的なポジションの平均価格の計算が誤っているからです。 でも面白いですね、この問題、熱烈なLoCKistである私の他には誰も気にしていないのかもしれませんね...。 :)) iExposureが失敗したのか、ネットが肩でたわんでいてこっそりやっているのか、どちらかです。 1...141516171819202122232425262728...33 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
何度も言うようですが、なぜなんでしょう？また、MT4とはどう違うのですか？
どうやらMT4では、ストップはポジションと注文ごとに設定されているようです。
しかし、5では、数学的なロックを実現するために、保留中の注文をストップとして配置する必要があります。
初期トレードのストップが「ロス」になってしまうから・・・。
ストップ: s-l と / または t-p など
SZZ：間違っているかもしれない
というのも、私はまだこの会計の話についていけてないので...。
どうやらMt4では、ストップはポジションごと 、注文ごとに独立して 設定されていたようです。
しかし、5では、例えば数学的なロックを実現するために、ストップとなる間を置く必要があるのです。
初期トレードのストップが「ロス」になってしまうから・・・。
停止：s-lと/またはt-pということですね。
それはわかったけど、なんで削除できないの？2つの保留中の注文を設定し、それらのチケットを記憶し、シンプルなブロックがそれらの可用性を監視し、1つがトリガーされると2つ目が削除される、要するにすべてはMT4と同じです...。
買ったのに、なぜ削除できないの？2つの注文を保留し、そのチケットを記憶し、シンプルなブロックがその可用性を監視し、1つがトリガーされると2つ目が削除される、要するに、すべてがMT4のようになる...ということです。
なぜなら、実際のカウントは「突然」不具合が出るわけではないので、確実に削除する必要があるからです。
との関連で、このテロップを消すには何というか、どのテロップを消せばいいのか...。
とにかく、こんな感じで...。
しかも、そのコンプはオンラインでなければならないことは言うまでもありません。>>ずっとです。>>わかりやすくするため。
買ったのに、なぜ削除できないの？2つの注文を保留し、そのチケットを記憶し、シンプルなブロックがその可用性を監視し、1つがトリガーされると2つ目が削除される、要するにすべてがMT4のようになる......ということです。
つまり、オフラインで保留中の注文が1つ発動すると、2つ目の注文がぶら下がったままになってしまうのです。
オフラインで1つの保留注文をトリガーすると、2つ目の保留注文はそこに留まるということです。
これは当然のことです。しかし、取引サーバーとの接続が完璧な場合のことも意味しています。MT5がマーケットターミナルであれば、指値注文はデプスチャートに理想的に配置でき、ストップ注文はマーケットオーダーとしてMetaTrader5 Execution server自体で実行されます。トレードサーバーに完璧に接続した状態で説明しています。
- ストップ注文は、現在保有中のポジションのStopLossとして設定されます。
- 現在保有中のポジションのTakeProfitとして、指値注文（ウィンドウ内）が設定されます。
- 重要なニュースが流れると、価格はストップオーダーに到達し、すぐに（1秒もかからずに）リミットオーダーに殺到する。(これらの命令が互いに近接している場合、この状況は非常に一般的です)。
その数ミリ秒の間に何が起こるのか。
- 執行サーバは、市場価格で逆指値注文を執行するための成行注文を送信します。
- 執行サーバーは、ストップオーダーが執行される価格を受信し、トレーダーに送信します。
- 執行サーバーは、指値注文が執行されたという通知を受け取り (MetaTrader5 の執行サーバーではなく ECN または取引所がその執行に責任を負う)、その情報をトレーダに送信します。
面白いのは、最後と最後のポイントが違う順番になることです。
そのため、両方の注文が実行され、トレーダーは、取引サーバーと完全に接続されている場合、Stop注文がトリガーされた後にLimit注文を削除することができませんでした。
追伸：この例は、指値注文を市場に出さず、成行注文として執行サーバーで執行する場合にも有効です。
P.P.S. 一般に、どうしても削除が間に合わないという状況があります。そこで、前述したFILL->KILLのオーダーの相互関係が有効である。
MetaTrader4でネット取引を行う方法を CodeBaseで提案し、バーチャルポジションの目的と実装のアイデアを提供しました。
アルパリのホームページでMQが言っていたことを思い出してみよう。
MetaTrader5では、取引部分には全く異なるアーキテクチャを採用しており、ポジションを別々に持つという考え方とは真逆のものになっています。同一システムで、個別と複合のポジション保有を組み合わせることは技術的に不可能である。
。
まだ1週間も経っていないのに、getchがMT4でネット取引を行うエレガントな 方法を提案しているのが分かる。
それ以外の場合は、から始まります。- "長い間考え、専門家に相談し..."
ただ、自分がミスをして、最後まで考えず 、当然の ように四半期ボーナスをもらったことを認めるのは、人間にとって非常につらい ことです。
MetaTrader4でネット取引を行う方法を CodeBaseで提案し、バーチャルポジションの目的と実装のアイデアを提供しました。
自分でも訂正します。
1.なぜ必要なのか？
2.一度に複数のポーズをとらないというシンプルな方法は適切ではないのでしょうか？
3.何を証明するのか？
アルパリのホームページでMQが言っていたことを思い出してください。
まだ1週間も経っていないのに、getch さんがMT4でネット取引をするエレガントな 方法を提案されているのがわかります。
2006年当時、同じMQがネッティング・トレーダーに対して、同じようにエレガントに提案した。
https://www.mql5.com/ru/forum/54564
2006年当時、この指標は配信に含まれているのですが...。
ネッティング業者がこれを使わないのは、一般的なポジションの平均価格の計算が誤っているからです。
でも面白いですね、この問題、熱烈なLoCKistである私の他には誰も気にしていないのかもしれませんね...。
:)) iExposureが失敗したのか、ネットが肩でたわんでいてこっそりやっているのか、どちらかです。