ストップロスはもう通用しない、負けることは負けるのだ。 - ページ 7 1234567 新しいコメント Roman 2019.09.09 09:16 #61 Aleksey Vyazmikin: 指値入札と成行入札、これはモスクワ取引所の正式な概念である。技術的な実装の問題は二の次で、一度に売買できないことは明らかで、ある頻度で収束することですべてが行われる。 他のすべての変動は、ブローカーのサーバー上の端末を通じて実現され、また、特定の条件が発生したときに、指値または成行注文に変換されます。 アドレスドオーダー、インパーソナルオーダー、リミットオーダー、アイスバーグリミットオーダー、ストップオーダー、ストップリミットオーダーがあります。ALL ! 成行注文がない！？ 成行買い注文（スラングと読みます）は、オファーより上の買い指値として執行されます。 成行売り注文（俗語読み）は、買値を下回る売り指値として執行されます。 そのため、マーケット・ストップ・オーダー（略してスラング）ですが、指値として取引所コアに送られます。 取引所では指値と見なしますので、ストップ注文のGOが必要です（あなたの場合、これはストップロス、またスラングです）。 取引所がマニュアルに書いていることは、取引所のスラングを適用しているのです 取引所の核となる部分は別の仕組みになっており、これを理解する必要があります。 ただ、アルゴリズム・プログラムを使う場合は、技術的な実装の問題が最重要です。 Aleksey Vyazmikin 2019.09.09 09:24 #62 Сергей Таболин:私見では、この議論は見当違いだと思います。TERMの概念が明確でないため。論理的には、ストップは逆の注文に置き換わるのと同じである（実際そうなっているのだが）。実行の優先順位の問題......これはもう、イエスですね。 つまり、指値注文はすでに取引所にあるが、各種ストップはブローカーの紙の上にしかないのだ。どうやらGOがすでにゼロとしてリミットで計上されている（具体的に確認すると、ターミナルではマージンが変化しない（MT5ではGO））ため、成行注文で執行されるためストップの実装が不可能であることがわかりました。あるいは、取引時ではなく、取引後にリスクと EBの計算された評価が行われるべきです。そうならないのは、ブローカーとそのソフトウェアのせい、あるいはルール・規制のせいである。 Aleksey Vyazmikin 2019.09.09 09:31 #63 Roman: リミットビッド、アイスバーグリミットビッド、ストップビッド、ストップリミットビッドがある。ALL ! 成行注文がない！？ 取引所がマニュアルに書いていることは、証券取引所のスラングを適用しているのだ! 取引所の核となる部分は別の仕組みになっており、これを理解する必要があります。 ただ、アルゴリズム的なプログラムを書く場合は、技術的な実装の問題が最重要です。 落ち着いてください :)法的な問題が第一、つまりメッセージは彼らがやりたいことで、実装は第二、メッセージと一致しないなら実装が間違っていて変えなければならない-これは、逆プロセス-科学研究の分野を除く、人間活動のこのような分野すべてに言えることである。 アイスバーグはソフトウェアで実装されるもので、私の知る限りPlaza2プロトコルでは提供されていない。 交換はソフトウェアを注文し、私はマニュアルではない引用し、それは法的に重要な文書である - 裁判では、それが優先され、交換はそれによって実際に動作しない場合、それはその側の違反です。 そして、条件以外の違いはありません。本質は変わりませんが、より重要なことは、注文には執行の優先順位にフラグがあり、マーケットメーカーの注文が最初に執行されることです。 ちなみに、技術的な実装については、私はこの引用が好きです。 トレーディング、自動売買システム、ストラテジーテストに関するフォーラム フィン・イン・スタック - 刻み目で何が起きたかを理解するために プロストトレーダー, 2019.04.19 19:31 そして、FORTSには確かに3種類のオーダーがあると主張します。 が、成行注文や指値注文ではありません（タイプ欄を参照）。 ちなみに、ここにはヘッジフィールドがあることに注意。どうやら、マーケットビッドやカウンターリミットビッドでCSを上げないようにするためのものらしい。 Roman 2019.09.09 10:07 #64 Aleksey Vyazmikin: 落ち着いてください :)法的な問題は一次的なもので、つまり前提は彼らがやりたかったことで、実装は二次的なもので、もしそれが前提に合致しないなら、実装は間違っていて変えなければならない--これは、逆プロセス、つまり科学研究の分野を除く、人間の活動のそうしたすべての領域で言えることである。 アイスバーグはソフトウェアで実装されるもので、私の知る限りPlaza2プロトコルでは提供されていない。 交換はソフトウェアを注文し、私はマニュアルではない引用し、それは法的に重要な文書である - 裁判では、それが優先され、交換はそれによって実際に動作しない場合、それはその側の違反です。 そして、条件以外の違いはありません。本質は変わりませんが、より重要なことは、注文には執行の優先順位にフラグがあり、マーケットメーカーの注文が最初に執行されることです。 ちなみに、技術的な実装については、私はこの引用が好きです。 ところで、ヘッジフィールドがあることに注意してください - 明らかにそれは、GOを増加させないことができます。 はい、法的なメッセージは理解しています。ただ、取引所での入札の仕事について、もう少し詳しく説明したかったのです。 このトピックを読んでいる人は、FXの後は、理解できないからです。 優先順位と実装については、すでにサーバーのMQの改良ではないと言っていますが、なぜチェックがないのでしょうか。 スクリーンショットとタイプに関しては、すべて正しく、ただ、いつものようにはっきりしない（わざと）書き方をしています。 クォーテーションビッドは、スタック内のビッドの限界値（流動性）です。 オポジット・ビッド - 流動性を奪うビッドです。 FOKオールオアナッシングが落札条件です。 しかし、これらの入札はすべて、基本的に取引所コアで指値として執行される )) 。 市場入札は観測されない )) モスバーガーは、常に規制が変化する一種の台所です。 ヘッジフィールドは、クリアリング前に、同じ商品で異なる指示のポジションを保有することができます。 ポジションが逆で数量が同じ入札は、CSで重なる、つまりゼロになる。 つまり、FXと 同じヘッジ です。 Quik端末では、このヘッジは注文へのコメントで行うことができる。 MQL注文の送信構造にもコメント欄があるが、同じかどうかは不明である。 Aleksey Vyazmikin 2019.09.09 10:22 #65 Roman: 優先順位と実装についてですが、すでにコメントさせていただきましたが、サーバーのMQの改善ではなく、なぜチェックがないのか、警告が出るのか、などです。 ブローカーとクリアリングセンターのどちらでチェックするのか、ブローカーであればクリアリングセンターのルールの運用に誤りがないのか、ここがまだ優先順位がはっきりしないところです。そして、サーバー（ブローカー）からクライアントへの情報がないことが問題なのです。クィックにもあるのかなぁ？ ローマン スクリーンショットとタイプについては、すべて正しいのですが、いつものようにはっきりしない書き方になっています（わざとです）。 クィックビッドはスタックでのビッドの限界値です。 カウンターアプリケーションとは、自分のCSポジションと重なるアプリケーションのことです。 FOKオールオアナッシングが入札の条件です。 市場入札は観測されない )) カウンタービッドは、オークション後に削除されると書いてありますが、オークションは情報の瞬間であり、指値注文はぶら下がったままなので、GOを増やさずに決済する方法は、マーケット（SL/TP含む）かプットの指値注文の2択なので、GOを減らすものだとは思えませんが、いかがでしょうか？どちらかというと、成行注文のように見えます。 ローマン フィールドヘッジでは、クリアリング前に、同じ商品で異なる指示のポジションを保有することができます。 数量が同じ入札は、CSで重なる、つまりゼロになる。 したがって、これはFXと 同じヘッジ である。 Quik端末では、このヘッジはリクエストへのコメントで行うことができる。 MQL注文の送信構造にもコメント用のフィールドがありますが、同じかどうかは不明です。 具体的にどのようなコメントが必要なのでしょうか？また、この場合、CSはどうなるのでしょうか？ Roman 2019.09.09 10:39 #66 Aleksey Vyazmikin: ブローカーとクリアリングセンターのどちらでチェックするのか、ブローカーであればクリアリングセンターのルールの運用に間違いがないのか、このあたりの優先順位がはっきりしないのです。そして、サーバー（ブローカー）からクライアントへの情報がないことが問題なのです。 クィックにもあるのかなぁ？ 反対注文がQRを減少させるというのは、オークション後に削除されると書いてあり、オークションは情報の瞬間ですが、指値注文はぶら下がったままなので、QRを増加させずに決済するには、成行（SL/TP含む）か成行で指値注文を入れるかの2択になるからです。 これこそ、注文の際のコメントでしょうか。また、この場合、SEはどうなるのでしょうか？ ブローカーでは、クリアリングはチェックを気にせず、セッションの結果をまとめていることがほとんどです。 はい、QuikはGOの不足を通知し、あなたのスクリーンショットから、mt5もお金がないことを通知していることが明らかでした。 しかし、ストップロスを閉じるためのお金がないのは、開発者が変えなければならない災難としか言いようがありません。 カウンタービッドとCSの件ですが、はい、私のミスです、ヘッジポジションの意味です。 ヘッジポジションが同量であれば、両注文のCSは互いに重なり、つまりゼロとなる。 50%重なると50%で無効化されるなど。 つまり、マーケットから離れた指値注文など、CSにかかる負荷を管理し、それらをオープンさせる予定がないものを管理することができます。 Quikの注文送信画面にコメント欄があり、何でも書ける、mqlの魔法みたいなものです。 しかし、コメント付きで発行されたポジションや 指値を決済 したい場合は、同じコメントを入力する必要があります。 また、ヘッジポジションはクリアするまで有効ですが、毎日クリアしているのか、折りたたんでいるのか覚えていません。夕方のメインクリアまで生きると思います。 Aleksey Vyazmikin 2019.09.09 11:01 #67 Roman: ブローカーの可能性が高く、クリアリングはチェックを気にせず、セッションの結果を合計します。 どうやって調べたらいいのか......まだ資料からではわからないのです。この件に関して、ブローカーや取引所、あるいはクリアリングセンターに手紙を書く可能性がある。 ローマン はい、QuikはGOの不足を通知し、スクリーンショットからmt5もお金の不足を通知していることが明らかでした。 Quikで再現してみなければならないのですが、TP/SLの設定方法がまだよくわかりません。 ブローカーはスクリーンショットを送ってくれ、それは彼らのサーバーで見ることができます。また、私はログを投稿しましたが、そのようなものは表示されません。つまり、証拠金不足の情報はありません（GO！）。 ローマン しかし、ストップロスを閉じるためのお金がないのは、開発者が変えなければならない災難としか言いようがありません。 もし、全てがルール通りに行われ、エラーがなければ、SLが発動した瞬間にカウンターリミットを外し、すぐに元に戻すべきです。あるいは、まったく戻さないこと。さもなければ、30%のポジションがTPではなくリミットオーダーで決済され、フリーズしなければストップがトリガーされないことになります。 ローマン ヘッジポジションの数量が同じであれば、両注文のCSは互いに重なり、すなわちゼロになる。 Quikの注文送信画面にコメント欄があり、何でも書ける、mqlの魔法みたいなものです。 しかし、コメント付きで発注したポジションや 指値を決済 したい場合は、同じコメントを入力する必要があります。 そして、ヘッジポジションはクリアまでしか有効でない、昼か夜か忘れたが、クリアする。夕方のメインクリアまで生きると思います。 ちなみに、Quikは開店・閉店後に利益があっても、なぜか清算前に資金が凍結された記憶があります...。セッションで使っていないGOでしか開けず、イライラしました...うーん、株もそうだったかな～忘れました～もう長いことスイッチ入れてませんしね。 Roman 2019.09.09 11:25 #68 Aleksey Vyazmikin: どうやって調べたらいいのか......まだ資料からではわからないのです。この件に関して、ブローカーや取引所、あるいはクリアリングセンターに手紙を書く可能性がある。 Quikで再現してみなければならないのですが、TP/SLの設定方法がまだよくわかりません。 ブローカーはスクリーンショットを送ってくれ、それは彼らのサーバーで見ることができ、私もログを並べましたが、そのようなものは表示されません - つまり、証拠金不足の情報はありません（GO！）。 もし、全てがルール通りに行われ、エラーがなければ、SLが発動した瞬間にカウンターリミットを外し、すぐに元に戻すべきです。あるいは、まったく戻さないこと。さもなければ、30%のポジションがTPではなくリミットオーダーで決済され、フリーズしなければストップがトリガーされないことになります。 ちなみに、Quikは開店・閉店後に利益があっても、なぜか清算前に資金が凍結された記憶があります...。セッションでまだ使っていないGOを使うしか開く方法がなくて困った...うーん、シェアもそうだったかなー、忘れた、長いこと使ってないし。 あ、なるほど、ブローカーのログのスクリーンショットなので、端末だけかと思ってました。 フォーラムでの取引に関する詳細については、取引システムと取引戦略のテストに関するフォーラムを参照してください。 手で開けようとしたら、開け方がわからなくなった。 アレクセイ・ヴャズミキン さん 2019.09.07 16:17 これは、彼らのシステムが状況をどのように認識しているかを示すスクリーンショットで、このメッセージはぐるぐる回っていました。 問題は、この6504.45という推定マージンがどこから出てきたのか、ということです。それは何から生まれたのでしょうか？売りの指値注文から買いの指値注文と同じ証拠金を差し引いたものが4500円となったが、その証拠金は、あたかもその瞬間に市場で始値を作る予定であるかのように計算されていることが判明したのだなぜ、そのように計画マージンを計算したのですか？ しかし、クライアント側でそれが実現できていないのは問題であり、非常に深刻な問題なのです。 開発者またはモデレーターがこのスレッドを読み、これがターミナルの深刻な問題であることを理解してくれることを望みます。 バグやエラーのスレッドで報告したほうがいいかもしれませんね。TP/SLの スラングは忘れて、常にリミットとストップでビッドを扱います。 ストップロス端末」用のGOが足りない場合は、指値注文があるかどうかをチェックして、あれば削除する、ということを以前書きました。 おそらくフリーズは前回のもので、クリアリングは夕方のクリアリングが終わってから始まり、翌日まで続くので、混乱する人も多いのでは？ 実は、今日の決済はすべて、昨夜の夕立の後に始まるのです )) 全3回の新たな現金決済を開始。 多くの人が思っているように、10時の開場からではない。 大体、市場が開くのは10時ではなく、夕方の清算が終わってからと解釈しています。 実はそうなのです。多くの人はこのことに気づいておらず、10時になっても取引は続いていますが、日中立会のままなのです。 それくらい、このMoSのやりとりは厄介なのです。 削除済み 2019.09.09 12:47 #69 すべてのトピックは「コントロール」されています。開発者が賛否両論を意識しているという意味で。たとえ、何も姿を見せずとも（言うことがないのか、恥ずかしいのか、それとも、私たちを気持ちよくさせるために、心に留めているのか？）)))) 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
指値入札と成行入札、これはモスクワ取引所の正式な概念である。技術的な実装の問題は二の次で、一度に売買できないことは明らかで、ある頻度で収束することですべてが行われる。
他のすべての変動は、ブローカーのサーバー上の端末を通じて実現され、また、特定の条件が発生したときに、指値または成行注文に変換されます。アドレスドオーダー、インパーソナルオーダー、リミットオーダー、アイスバーグリミットオーダー、ストップオーダー、ストップリミットオーダーがあります。ALL !
成行注文がない！？
成行買い注文（スラングと読みます）は、オファーより上の買い指値として執行されます。
成行売り注文（俗語読み）は、買値を下回る売り指値として執行されます。
そのため、マーケット・ストップ・オーダー（略してスラング）ですが、指値として取引所コアに送られます。
取引所では指値と見なしますので、ストップ注文のGOが必要です（あなたの場合、これはストップロス、またスラングです）。
取引所がマニュアルに書いていることは、取引所のスラングを適用しているのです
取引所の核となる部分は別の仕組みになっており、これを理解する必要があります。
ただ、アルゴリズム・プログラムを使う場合は、技術的な実装の問題が最重要です。
私見では、この議論は見当違いだと思います。TERMの概念が明確でないため。
論理的には、ストップは逆の注文に置き換わるのと同じである（実際そうなっているのだが）。実行の優先順位の問題......これはもう、イエスですね。
つまり、指値注文はすでに取引所にあるが、各種ストップはブローカーの紙の上にしかないのだ。どうやらGOがすでにゼロとしてリミットで計上されている（具体的に確認すると、ターミナルではマージンが変化しない（MT5ではGO））ため、成行注文で執行されるためストップの実装が不可能であることがわかりました。あるいは、取引時ではなく、取引後にリスクと EBの計算された評価が行われるべきです。そうならないのは、ブローカーとそのソフトウェアのせい、あるいはルール・規制のせいである。
リミットビッド、アイスバーグリミットビッド、ストップビッド、ストップリミットビッドがある。ALL !
成行注文がない！？
取引所がマニュアルに書いていることは、証券取引所のスラングを適用しているのだ!
取引所の核となる部分は別の仕組みになっており、これを理解する必要があります。
ただ、アルゴリズム的なプログラムを書く場合は、技術的な実装の問題が最重要です。
落ち着いてください :)法的な問題が第一、つまりメッセージは彼らがやりたいことで、実装は第二、メッセージと一致しないなら実装が間違っていて変えなければならない-これは、逆プロセス-科学研究の分野を除く、人間活動のこのような分野すべてに言えることである。
アイスバーグはソフトウェアで実装されるもので、私の知る限りPlaza2プロトコルでは提供されていない。
交換はソフトウェアを注文し、私はマニュアルではない引用し、それは法的に重要な文書である - 裁判では、それが優先され、交換はそれによって実際に動作しない場合、それはその側の違反です。
そして、条件以外の違いはありません。本質は変わりませんが、より重要なことは、注文には執行の優先順位にフラグがあり、マーケットメーカーの注文が最初に執行されることです。
ちなみに、技術的な実装については、私はこの引用が好きです。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
フィン・イン・スタック - 刻み目で何が起きたかを理解するために
プロストトレーダー, 2019.04.19 19:31
そして、FORTSには確かに3種類のオーダーがあると主張します。
が、成行注文や指値注文ではありません（タイプ欄を参照）。
落ち着いてください :)法的な問題は一次的なもので、つまり前提は彼らがやりたかったことで、実装は二次的なもので、もしそれが前提に合致しないなら、実装は間違っていて変えなければならない--これは、逆プロセス、つまり科学研究の分野を除く、人間の活動のそうしたすべての領域で言えることである。
アイスバーグはソフトウェアで実装されるもので、私の知る限りPlaza2プロトコルでは提供されていない。
交換はソフトウェアを注文し、私はマニュアルではない引用し、それは法的に重要な文書である - 裁判では、それが優先され、交換はそれによって実際に動作しない場合、それはその側の違反です。
そして、条件以外の違いはありません。本質は変わりませんが、より重要なことは、注文には執行の優先順位にフラグがあり、マーケットメーカーの注文が最初に執行されることです。
ちなみに、技術的な実装については、私はこの引用が好きです。
はい、法的なメッセージは理解しています。ただ、取引所での入札の仕事について、もう少し詳しく説明したかったのです。
このトピックを読んでいる人は、FXの後は、理解できないからです。
優先順位と実装については、すでにサーバーのMQの改良ではないと言っていますが、なぜチェックがないのでしょうか。
スクリーンショットとタイプに関しては、すべて正しく、ただ、いつものようにはっきりしない（わざと）書き方をしています。
クォーテーションビッドは、スタック内のビッドの限界値（流動性）です。
オポジット・ビッド - 流動性を奪うビッドです。
FOKオールオアナッシングが落札条件です。
しかし、これらの入札はすべて、基本的に取引所コアで指値として執行される )) 。
市場入札は観測されない ))
モスバーガーは、常に規制が変化する一種の台所です。
ヘッジフィールドは、クリアリング前に、同じ商品で異なる指示のポジションを保有することができます。
ポジションが逆で数量が同じ入札は、CSで重なる、つまりゼロになる。
つまり、FXと 同じヘッジ です。
Quik端末では、このヘッジは注文へのコメントで行うことができる。
MQL注文の送信構造にもコメント欄があるが、同じかどうかは不明である。
優先順位と実装についてですが、すでにコメントさせていただきましたが、サーバーのMQの改善ではなく、なぜチェックがないのか、警告が出るのか、などです。
ブローカーとクリアリングセンターのどちらでチェックするのか、ブローカーであればクリアリングセンターのルールの運用に誤りがないのか、ここがまだ優先順位がはっきりしないところです。そして、サーバー（ブローカー）からクライアントへの情報がないことが問題なのです。クィックにもあるのかなぁ？
スクリーンショットとタイプについては、すべて正しいのですが、いつものようにはっきりしない書き方になっています（わざとです）。
クィックビッドはスタックでのビッドの限界値です。
カウンターアプリケーションとは、自分のCSポジションと重なるアプリケーションのことです。
FOKオールオアナッシングが入札の条件です。
市場入札は観測されない ))
カウンタービッドは、オークション後に削除されると書いてありますが、オークションは情報の瞬間であり、指値注文はぶら下がったままなので、GOを増やさずに決済する方法は、マーケット（SL/TP含む）かプットの指値注文の2択なので、GOを減らすものだとは思えませんが、いかがでしょうか？どちらかというと、成行注文のように見えます。
フィールドヘッジでは、クリアリング前に、同じ商品で異なる指示のポジションを保有することができます。
数量が同じ入札は、CSで重なる、つまりゼロになる。
したがって、これはFXと 同じヘッジ である。
Quik端末では、このヘッジはリクエストへのコメントで行うことができる。
MQL注文の送信構造にもコメント用のフィールドがありますが、同じかどうかは不明です。
具体的にどのようなコメントが必要なのでしょうか？また、この場合、CSはどうなるのでしょうか？
ブローカーとクリアリングセンターのどちらでチェックするのか、ブローカーであればクリアリングセンターのルールの運用に間違いがないのか、このあたりの優先順位がはっきりしないのです。そして、サーバー（ブローカー）からクライアントへの情報がないことが問題なのです。 クィックにもあるのかなぁ？
反対注文がQRを減少させるというのは、オークション後に削除されると書いてあり、オークションは情報の瞬間ですが、指値注文はぶら下がったままなので、QRを増加させずに決済するには、成行（SL/TP含む）か成行で指値注文を入れるかの2択になるからです。
これこそ、注文の際のコメントでしょうか。また、この場合、SEはどうなるのでしょうか？
ブローカーでは、クリアリングはチェックを気にせず、セッションの結果をまとめていることがほとんどです。
はい、QuikはGOの不足を通知し、あなたのスクリーンショットから、mt5もお金がないことを通知していることが明らかでした。
しかし、ストップロスを閉じるためのお金がないのは、開発者が変えなければならない災難としか言いようがありません。
カウンタービッドとCSの件ですが、はい、私のミスです、ヘッジポジションの意味です。
ヘッジポジションが同量であれば、両注文のCSは互いに重なり、つまりゼロとなる。
50%重なると50%で無効化されるなど。
つまり、マーケットから離れた指値注文など、CSにかかる負荷を管理し、それらをオープンさせる予定がないものを管理することができます。
Quikの注文送信画面にコメント欄があり、何でも書ける、mqlの魔法みたいなものです。
しかし、コメント付きで発行されたポジションや 指値を決済 したい場合は、同じコメントを入力する必要があります。
また、ヘッジポジションはクリアするまで有効ですが、毎日クリアしているのか、折りたたんでいるのか覚えていません。夕方のメインクリアまで生きると思います。
ブローカーの可能性が高く、クリアリングはチェックを気にせず、セッションの結果を合計します。
どうやって調べたらいいのか......まだ資料からではわからないのです。この件に関して、ブローカーや取引所、あるいはクリアリングセンターに手紙を書く可能性がある。
はい、QuikはGOの不足を通知し、スクリーンショットからmt5もお金の不足を通知していることが明らかでした。
Quikで再現してみなければならないのですが、TP/SLの設定方法がまだよくわかりません。
ブローカーはスクリーンショットを送ってくれ、それは彼らのサーバーで見ることができます。また、私はログを投稿しましたが、そのようなものは表示されません。つまり、証拠金不足の情報はありません（GO！）。
しかし、ストップロスを閉じるためのお金がないのは、開発者が変えなければならない災難としか言いようがありません。
もし、全てがルール通りに行われ、エラーがなければ、SLが発動した瞬間にカウンターリミットを外し、すぐに元に戻すべきです。あるいは、まったく戻さないこと。さもなければ、30%のポジションがTPではなくリミットオーダーで決済され、フリーズしなければストップがトリガーされないことになります。
ヘッジポジションの数量が同じであれば、両注文のCSは互いに重なり、すなわちゼロになる。
Quikの注文送信画面にコメント欄があり、何でも書ける、mqlの魔法みたいなものです。
しかし、コメント付きで発注したポジションや 指値を決済 したい場合は、同じコメントを入力する必要があります。
そして、ヘッジポジションはクリアまでしか有効でない、昼か夜か忘れたが、クリアする。夕方のメインクリアまで生きると思います。
ちなみに、Quikは開店・閉店後に利益があっても、なぜか清算前に資金が凍結された記憶があります...。セッションで使っていないGOでしか開けず、イライラしました...うーん、株もそうだったかな～忘れました～もう長いことスイッチ入れてませんしね。
どうやって調べたらいいのか......まだ資料からではわからないのです。この件に関して、ブローカーや取引所、あるいはクリアリングセンターに手紙を書く可能性がある。
Quikで再現してみなければならないのですが、TP/SLの設定方法がまだよくわかりません。
ブローカーはスクリーンショットを送ってくれ、それは彼らのサーバーで見ることができ、私もログを並べましたが、そのようなものは表示されません - つまり、証拠金不足の情報はありません（GO！）。
もし、全てがルール通りに行われ、エラーがなければ、SLが発動した瞬間にカウンターリミットを外し、すぐに元に戻すべきです。あるいは、まったく戻さないこと。さもなければ、30%のポジションがTPではなくリミットオーダーで決済され、フリーズしなければストップがトリガーされないことになります。
ちなみに、Quikは開店・閉店後に利益があっても、なぜか清算前に資金が凍結された記憶があります...。セッションでまだ使っていないGOを使うしか開く方法がなくて困った...うーん、シェアもそうだったかなー、忘れた、長いこと使ってないし。
あ、なるほど、ブローカーのログのスクリーンショットなので、端末だけかと思ってました。
フォーラムでの取引に関する詳細については、取引システムと取引戦略のテストに関するフォーラムを参照してください。
手で開けようとしたら、開け方がわからなくなった。
アレクセイ・ヴャズミキン さん 2019.09.07 16:17
これは、彼らのシステムが状況をどのように認識しているかを示すスクリーンショットで、このメッセージはぐるぐる回っていました。
問題は、この6504.45という推定マージンがどこから出てきたのか、ということです。それは何から生まれたのでしょうか？売りの指値注文から買いの指値注文と同じ証拠金を差し引いたものが4500円となったが、その証拠金は、あたかもその瞬間に市場で始値を作る予定であるかのように計算されていることが判明したのだなぜ、そのように計画マージンを計算したのですか？
しかし、クライアント側でそれが実現できていないのは問題であり、非常に深刻な問題なのです。
開発者またはモデレーターがこのスレッドを読み、これがターミナルの深刻な問題であることを理解してくれることを望みます。
バグやエラーのスレッドで報告したほうがいいかもしれませんね。
TP/SLの スラングは忘れて、常にリミットとストップでビッドを扱います。
ストップロス端末」用のGOが足りない場合は、指値注文があるかどうかをチェックして、あれば削除する、ということを以前書きました。
おそらくフリーズは前回のもので、クリアリングは夕方のクリアリングが終わってから始まり、翌日まで続くので、混乱する人も多いのでは？
実は、今日の決済はすべて、昨夜の夕立の後に始まるのです ))
全3回の新たな現金決済を開始。
多くの人が思っているように、10時の開場からではない。
大体、市場が開くのは10時ではなく、夕方の清算が終わってからと解釈しています。
実はそうなのです。多くの人はこのことに気づいておらず、10時になっても取引は続いていますが、日中立会のままなのです。
それくらい、このMoSのやりとりは厄介なのです。