エラー、バグ、質問 - ページ 399 1...392393394395396397398399400401402403404405406...3185 新しいコメント 削除済み 2011.06.01 21:16 #3981 papaklassさん、 お返事ありがとうございます。例(繰り返しになってしまうかもしれませんが)。最小ロット=1.0、最小ロットステップ=0.1。相場が下落し始めたので、トレーダーは10.1ロットのロングポジションを決済しようとします。ニュース市場の場合、ORDER_FILLING_AONの注文が実行されないことがあります。RDER_FILLING_CANCEL を使用するのがより合理的です。反対売買の売りが一部(10.0ロット)約定。残りのロングポジション(0.1ロット)は、引き続き損失が発生しています。取引の最小ロット=1.0ロットであるため、決済することはできません。すなわち、市場から完全に退出するためには、トレーダーはしなければならない。1.最低1.0ロット以上購入し、明らかな損失を出すこと。2.ORDER_FILLING_AONパラメータで1.1Lotの売り取引を実行してみる。つまり、常識的に考えて、ORDER_FILLING_CANCELとORDER_FILLING_RETURNを 入力すると、最小ロットと最小ロットの増分の値が等しくなければならないという厳しい条件が課されることになるのです。もう一つの例。1.0ロットのロングポジションがあり、SL/TPが設定されています。1.1Lotの数量で、指定したSL/TP(売り)で反対売買を行おうとする。このような数量が市場で入手可能であり、結果として得られるポジションは、 - 0.1ロットの売り数量、指定されたSL/TP(売りの場合) - となるとします。しかし、そのようなボリュームはなく、ORDER_FILLING_CANCELがあるのでは?SL/TPが違うというエラーが出ます。したがって、控えめに言って、クロス取引ではORDER_FILLING_CANCELパラメータでSL/TP = 0を送るのが知恵となります。MQL5のプログラマーは賢い人が多いと思いますが、開発者から順序配置の正誤検証のアルゴリズムについて説明する記事があっても良いと思います。繰り返し質問させていただきます。そのような記事は存在するのでしょうか?もしそうでなければ、早く登場してほしいですか? Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров www.mql5.com Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5 削除済み 2011.06.01 22:24 #3982 papaklass: 注文が成立 したとき、残りのポジションの数量が最小値を下回ることはできません。なぜ、そう言い切れるのですか?一つ上の投稿で、そのような状況があり得る場合の例(第一回目)が紹介されていました。サーバーが特別な 特徴 注文を部分的に決済して、残りが最小ロットより少なくなることを防ぐことができます。このことは、ドキュメントのどこに明示的に書かれているのでしょうか? 削除済み 2011.06.01 23:14 #3983 voix_kas:なぜ、そう言い切れるのですか?一つ上の投稿で、そのような状況があり得る場合の例(第一回目)が紹介されていました。サーバーに特別なルールがあり、注文を部分的に閉じることができないかのどちらかです。 機能 あるいは、残高を最小ロット以下に抑えるために、注文を部分的に閉じることができないようにする特別なコードが存在します。このことは、ドキュメントのどこに明示的に書かれているのでしょうか?これはまさにサーバーに書かれていることです(最後の例と同じ)。おそらく端末の反応も間に合い、明らかな誤操作を防ぐことができるだろう。あらゆる論理的ルールにより、最小ロット未満の取引や、最小ロット未満の商品の数量を 変更する/露出させるような取引を行うことは不可能である。 削除済み 2011.06.01 23:30 #3984 Interesting:これは、まさに(最終的な権威として)サーバーに指定されているものです。おそらく端末の反応も間に合い、明らかな誤操作を防ぐことができるだろう。すべての論理的なルールでは、最小ロット未満の取引と、最小ロット未満のポジションの数量を 変更する/公開するような取引を実行することはできません。サーバー上の...」とは、具体的に何をどこに書いてあるのでしょうか?あなたのメッセージの中には、憶測という悪いものが一つあります。直球勝負で申し訳ないです。:-)最小ロット未満の取引を部分的に実行することは禁止されている、と明記されているドキュメントへの リンクを教えてください。 削除済み 2011.06.01 23:39 #3985 voix_kas:サーバー上で...」とは、具体的にどこをどうすればいいのでしょうか?あなたの書き込みには、憶測という悪い点があります。直球で反対したことをお許しください。:-)残高が最小ロットを下回るような取引の部分的な実行を禁止する」と明記されているドキュメントの 具体的なリンク先を教えてください。Alpari(私の記憶に間違いがなければ、彼らの最小ロットは0.10です)で、0.01のロットを開くために何のチェックもないスクリプトで試してみてください。このアカウントでレスポンス(構造体の情報)がどのように返ってくるか見てみましょう。また、2010 年のアカウントでストラテジーテスターの Expert Advisorを0.01ロットで動かしてみることもできます。その後、何がどこで可能なのか、実質的な話を続けていきます。 voix_kas です。最小ロット未満の取引を部分的に実行することは禁止されています。水素原子は、水素原子よりも小さくなることができるのだろうか。おそらくできるだろうが、そうなると、もはや我々の宇宙や「我々の」物理法則ではなくなってしまう...。また、「ABC」と「数学の基礎」では、ドキュメントのどの部分にこのことを書けばいいのでしょうか?直球勝負で申し訳ないです。:-) Automated Trading Championship 2010 championship.mql5.com Automated Trading Championship 2010 削除済み 2011.06.01 23:48 #3986 Interesting:Alpari(私の記憶に間違いがなければ、彼らは0.10の最小ロットを持っています)で、例えば0.01のロットを開くために何のチェックもせずにスクリプトで試してみてください。レスポンスでこのアカウントに何が返されるかを確認する(構造体の情報)。また、2010 年のアカウントでストラテジーテスターの Expert Advisorを0.01ロットで動かしてみることもできます。その後、何がどこで可能なのか、実質的な話を続けていきます。直球勝負で申し訳ないです。:-)拝啓、私の質問をお読みになられましたか。特定の口座/口座タイプで最小設定ロットより少ない数量で取引を行うことが可能かどうかを尋ねているのではありません。もちろん、そんなことはありません。MQL5の概念からすると、最小許容ロットより少ない部分ロットで取引を実行してもよいのでしょうか? もちろん、ORDER_FILLING_CANCELとORDER_FILLING_RETURNについて話して います)。また、経験則ではなく、公式に発表されているMQL5「エンジン」の具体的な要件・制限について話しています。 Sergey Gritsay 2011.06.01 23:56 #3987 voix_kas: 拝啓、私の質問をお読みになられましたか。特定の口座/口座タイプで最小設定ロット未満の数量で取引を行うことが可能かどうかを尋ねているのではありません。もちろん、そんなことはありません。MQL5のコンセプトからすると、最小許容ロットより少ない部分ロットで取引を実行してもよいのでしょうか? もちろん、ORDER_FILLING_CANCELとORDER_FILLING_RETURNについて です)。また、経験則ではなく、公式に発表されているMQL5「エンジン」の具体的な要件・制限について話しています。 今、手動で確認しましたが、すべて問題なく閉じます。0.21ロットの買いを建て、0.2ロットの売りを決済しました。最小値は0.1ロットですが、買いポジションは0.01ロットのままです。四重奏で確認しましたが、そちらでも部分閉鎖のエラーはありません。 Валерий 2011.06.02 00:01 #3988 papaklass: 注文が成立したとき、残りのポジションの数量が最小の 数量より少なくなることはありません。最小容量の倍数となり、それ以下にはなりません。 最小可能ロットを0.1として、0.01ロット単位でポジションを変更できる例を教えてください。そうすれば、あなた自身の質問に答えることができるでしょう。あなたの解釈は明快です。でも、ドキュメントを見てください。 SYMBOL_VOLUME_MIN取引の 最小量 SYMBOL_VOLUME_STEP取引 成立のための出来高変化量の最小ステップつまり、この例では、0.1、0.11、0.12...の出来高の取引(したがって注文)が可能です。などであり、不可能は0.09、0.08、0.07・・・などです。まさにディール、ポジションボリュームについては何も語られていない。例えば、1.0ロットの買いポジションを持ち、0.95ロットの売りで部分的に決済した場合(これは出来高粒度の条件に相当)、0.05ロットの出来高のポジションを持つことになります。そして、今さら閉じるわけにもいきません。まず、ポジションを少なくとも1.05まで増やし(注文は0.1以下にはできない)、それから完全にクローズする必要があります。オープンポジションを完全にクローズすることができないのは不合理です。 Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация об инструменте www.mql5.com Стандартные константы, перечисления и структуры / Состояние окружения / Информация об инструменте - Документация по MQL5 削除済み 2011.06.02 00:03 #3989 sergey1294: 今、手動で確認しましたが、完璧に閉じますね。0.21ロットで買いポジションを建て、0.2ロットで売りポジションを決済したところ、最低0.1ロットでしたが0.01ロットが市場に残っています。4でも確認したのですが、そちらでも部分終了のエラーはありません。0.01ロットの残りのポジションは、同じ数量の反対売買で決済されるのでしょうか?つまり、出来高0.01の売り取引が成立する(もちろん、オープンポジションは 完全にクローズする)のでしょうか? 削除済み 2011.06.02 00:03 #3990 voix_kas: 拝啓、私の質問をお読みになられましたか。特定の口座/口座タイプで最小設定ロット未満の数量で取引を行うことが可能かどうかを尋ねているのではありません。もちろん、そんなことはありません。MQL5の概念からすると、最小許容ロットより少ない部分ロットで取引を実行してもよいのでしょうか? もちろん、ORDER_FILLING_CANCELとORDER_FILLING_RETURNについて話して います)。経験則ではなく、公式に発表されたMQL5の具体的な要件/制限について話しています。答えは簡単で、あらゆる条件下で、不可能であり、許さ れない(そうでなければ、一気にSDに入る。そして、クライアント部分のテスターである「我々」だけでなく、サーバー部分をテストしているブローカーも憤慨していることでしょう)。ご質問の技術的な部分についてお答えしますと、クライアント側(端末とテスター)にはチェックが入っており、サーバー側には何の疑いもなくチェックが入るということです。クライアント側のチェックは、第一にあらゆる取引条件・ルール違反を事前に発見するため、第二にサーバーの負荷を軽減し、不正なリクエストによる「攻撃」を防ぐために必要である(端末は取引ルール違反や明らかなリクエストミスを検知するとサーバーにリクエストを送るだけでは済まないのだ)。一方、サーバも(最終権限者として)取引要求の正しさ(この要求の実行によって予想される結果の正しさを含む)を必ず確認することになる。 1...392393394395396397398399400401402403404405406...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
papaklassさん、 お返事ありがとうございます。
例(繰り返しになってしまうかもしれませんが)。
最小ロット=1.0、最小ロットステップ=0.1。相場が下落し始めたので、トレーダーは10.1ロットのロングポジションを決済しようとします。ニュース市場の場合、ORDER_FILLING_AONの注文が実行されないことがあります。RDER_FILLING_CANCEL を使用するのがより合理的です。反対売買の売りが一部(10.0ロット)約定。残りのロングポジション(0.1ロット)は、引き続き損失が発生しています。取引の最小ロット=1.0ロットであるため、決済することはできません。すなわち、市場から完全に退出するためには、トレーダーはしなければならない。
1.最低1.0ロット以上購入し、明らかな損失を出すこと。
2.ORDER_FILLING_AONパラメータで1.1Lotの売り取引を実行してみる。
つまり、常識的に考えて、ORDER_FILLING_CANCELとORDER_FILLING_RETURNを 入力すると、最小ロットと最小ロットの増分の値が等しくなければならないという厳しい条件が課されることになるのです。
もう一つの例。
1.0ロットのロングポジションがあり、SL/TPが設定されています。1.1Lotの数量で、指定したSL/TP(売り)で反対売買を行おうとする。
このような数量が市場で入手可能であり、結果として得られるポジションは、 - 0.1ロットの売り数量、指定されたSL/TP(売りの場合) - となるとします。
しかし、そのようなボリュームはなく、ORDER_FILLING_CANCELがあるのでは?SL/TPが違うというエラーが出ます。したがって、控えめに言って、クロス取引ではORDER_FILLING_CANCELパラメータでSL/TP = 0を送るのが知恵となります。
MQL5のプログラマーは賢い人が多いと思いますが、開発者から順序配置の正誤検証のアルゴリズムについて説明する記事があっても良いと思います。
繰り返し質問させていただきます。そのような記事は存在するのでしょうか?もしそうでなければ、早く登場してほしいですか?
注文が成立 したとき、残りのポジションの数量が最小値を下回ることはできません。
なぜ、そう言い切れるのですか?
一つ上の投稿で、そのような状況があり得る場合の例(第一回目)が紹介されていました。
サーバーが特別な 特徴 注文を部分的に決済して、残りが最小ロットより少なくなることを防ぐことができます。このことは、ドキュメントのどこに明示的に書かれているのでしょうか?
なぜ、そう言い切れるのですか?
一つ上の投稿で、そのような状況があり得る場合の例(第一回目)が紹介されていました。
サーバーに特別なルールがあり、注文を部分的に閉じることができないかのどちらかです。 機能 あるいは、残高を最小ロット以下に抑えるために、注文を部分的に閉じることができないようにする特別なコードが存在します。このことは、ドキュメントのどこに明示的に書かれているのでしょうか?
これはまさにサーバーに書かれていることです(最後の例と同じ)。おそらく端末の反応も間に合い、明らかな誤操作を防ぐことができるだろう。
あらゆる論理的ルールにより、最小ロット未満の取引や、最小ロット未満の商品の数量を 変更する/露出させるような取引を行うことは不可能である。
これは、まさに(最終的な権威として)サーバーに指定されているものです。おそらく端末の反応も間に合い、明らかな誤操作を防ぐことができるだろう。
すべての論理的なルールでは、最小ロット未満の取引と、最小ロット未満のポジションの数量を 変更する/公開するような取引を実行することはできません。
サーバー上の...」とは、具体的に何をどこに書いてあるのでしょうか?
あなたのメッセージの中には、憶測という悪いものが一つあります。直球勝負で申し訳ないです。:-)
最小ロット未満の取引を部分的に実行することは禁止されている、と明記されているドキュメントへの リンクを教えてください。
サーバー上で...」とは、具体的にどこをどうすればいいのでしょうか?
あなたの書き込みには、憶測という悪い点があります。直球で反対したことをお許しください。:-)
残高が最小ロットを下回るような取引の部分的な実行を禁止する」と明記されているドキュメントの 具体的なリンク先を教えてください。
Alpari(私の記憶に間違いがなければ、彼らの最小ロットは0.10です)で、0.01のロットを開くために何のチェックもないスクリプトで試してみてください。
このアカウントでレスポンス(構造体の情報)がどのように返ってくるか見てみましょう。
また、2010 年のアカウントでストラテジーテスターの Expert Advisorを0.01ロットで動かしてみることもできます。
その後、何がどこで可能なのか、実質的な話を続けていきます。
voix_kas です。
最小ロット未満の取引を部分的に実行することは禁止されています。
水素原子は、水素原子よりも小さくなることができるのだろうか。おそらくできるだろうが、そうなると、もはや我々の宇宙や「我々の」物理法則ではなくなってしまう...。
また、「ABC」と「数学の基礎」では、ドキュメントのどの部分にこのことを書けばいいのでしょうか?
直球勝負で申し訳ないです。:-)
Alpari(私の記憶に間違いがなければ、彼らは0.10の最小ロットを持っています)で、例えば0.01のロットを開くために何のチェックもせずにスクリプトで試してみてください。
レスポンスでこのアカウントに何が返されるかを確認する(構造体の情報)。
また、2010 年のアカウントでストラテジーテスターの Expert Advisorを0.01ロットで動かしてみることもできます。
その後、何がどこで可能なのか、実質的な話を続けていきます。
直球勝負で申し訳ないです。:-)
拝啓、私の質問をお読みになられましたか。
特定の口座/口座タイプで最小設定ロットより少ない数量で取引を行うことが可能かどうかを尋ねているのではありません。もちろん、そんなことはありません。
MQL5の概念からすると、最小許容ロットより少ない部分ロットで取引を実行してもよいのでしょうか? もちろん、ORDER_FILLING_CANCELとORDER_FILLING_RETURNについて話して います)。
また、経験則ではなく、公式に発表されているMQL5「エンジン」の具体的な要件・制限について話しています。
拝啓、私の質問をお読みになられましたか。
特定の口座/口座タイプで最小設定ロット未満の数量で取引を行うことが可能かどうかを尋ねているのではありません。もちろん、そんなことはありません。
MQL5のコンセプトからすると、最小許容ロットより少ない部分ロットで取引を実行してもよいのでしょうか? もちろん、ORDER_FILLING_CANCELとORDER_FILLING_RETURNについて です)。
また、経験則ではなく、公式に発表されているMQL5「エンジン」の具体的な要件・制限について話しています。
注文が成立したとき、残りのポジションの数量が最小の 数量より少なくなることはありません。最小容量の倍数となり、それ以下にはなりません。
最小可能ロットを0.1として、0.01ロット単位でポジションを変更できる例を教えてください。そうすれば、あなた自身の質問に答えることができるでしょう。
あなたの解釈は明快です。でも、ドキュメントを見てください。
SYMBOL_VOLUME_MIN取引の 最小量
SYMBOL_VOLUME_STEP取引 成立のための出来高変化量の最小ステップ
つまり、この例では、0.1、0.11、0.12...の出来高の取引(したがって注文)が可能です。など
であり、不可能は0.09、0.08、0.07・・・などです。
まさにディール、ポジションボリュームについては何も語られていない。
例えば、1.0ロットの買いポジションを持ち、0.95ロットの売りで部分的に決済した場合(これは出来高粒度の条件に相当)、0.05ロットの出来高のポジションを持つことになります。そして、今さら閉じるわけにもいきません。
まず、ポジションを少なくとも1.05まで増やし(注文は0.1以下にはできない)、それから完全にクローズする必要があります。
オープンポジションを完全にクローズすることができないのは不合理です。
今、手動で確認しましたが、完璧に閉じますね。0.21ロットで買いポジションを建て、0.2ロットで売りポジションを決済したところ、最低0.1ロットでしたが0.01ロットが市場に残っています。4でも確認したのですが、そちらでも部分終了のエラーはありません。
0.01ロットの残りのポジションは、同じ数量の反対売買で決済されるのでしょうか?
つまり、出来高0.01の売り取引が成立する(もちろん、オープンポジションは 完全にクローズする)のでしょうか?
拝啓、私の質問をお読みになられましたか。
特定の口座/口座タイプで最小設定ロット未満の数量で取引を行うことが可能かどうかを尋ねているのではありません。もちろん、そんなことはありません。
MQL5の概念からすると、最小許容ロットより少ない部分ロットで取引を実行してもよいのでしょうか? もちろん、ORDER_FILLING_CANCELとORDER_FILLING_RETURNについて話して います)。
経験則ではなく、公式に発表されたMQL5の具体的な要件/制限について話しています。
答えは簡単で、あらゆる条件下で、不可能であり、許さ れない(そうでなければ、一気にSDに入る。そして、クライアント部分のテスターである「我々」だけでなく、サーバー部分をテストしているブローカーも憤慨していることでしょう)。
ご質問の技術的な部分についてお答えしますと、クライアント側(端末とテスター)にはチェックが入っており、サーバー側には何の疑いもなくチェックが入るということです。
クライアント側のチェックは、第一にあらゆる取引条件・ルール違反を事前に発見するため、第二にサーバーの負荷を軽減し、不正なリクエストによる「攻撃」を防ぐために必要である(端末は取引ルール違反や明らかなリクエストミスを検知するとサーバーにリクエストを送るだけでは済まないのだ)。
一方、サーバも(最終権限者として)取引要求の正しさ(この要求の実行によって予想される結果の正しさを含む)を必ず確認することになる。