エラー、バグ、質問 - ページ 68 1...616263646566676869707172737475...3185 新しいコメント Alexey Petrov 2010.07.27 16:24 #671 kirill190982: こんにちは、CFD商品には制限があること、つまり注文の種類が SLとTPを除く日中であることを正しく理解しているかどうか助言してください。つまり、もし私が正しいのであれば、どのような関数を使えば、SLやTPを置くべきでないことを検出できるのでしょうか。ありがとうございました。これらのキャラクターは、サーバー上で設定します。これは、ストップ・レベルを設定できないことを意味するものではありません。取引日の終了後、保留中の注文は削除され、オープンポジションのストップレベルは保持されます。この設定は、現時点ではMQL5から確認することはできません。 削除済み 2010.07.28 10:17 #672 アカウント制限量 1シンボルにつきオープンポジションとペンディングオーダー(方向に関係なく)の最大許容合算量 二重開発者に感謝 - 注文制限に感謝しますが、この場合、何が書いてあって、どう理解すべきなのかよくわかりません。:(保留中の注文に関する部分に困惑しています。なぜここに追加されたのか、その理由を教えてください。私の理解では、「オープンポジションの 合計の最大値」というような表現になるはずです。このことは、それ自体、トリガーされる前の保留中の注文は、いかなる形でもここに関係すべきではなく、この条件の制御は、(注文がトリガーされた事実について)サーバーによって行われることを意味します。追記現在は0が 返され(制限がかかっていないという意味と受け止めています)、チャンピオンシップ期間中は15.0が 返されるはずです。そうだろうか? Rashid Umarov 2010.07.28 10:24 #673 Interesting:アカウント制限量 1シンボルにつきオープンポジションとペンディングオーダー(方向に関係なく)の最大許容合算量 二重開発者に感謝 - 注文制限に感謝しますが、この場合、何が書いてあって、どう理解すべきなのかよくわかりません。:(保留中の注文に関する部分に困惑しています。なぜここに追加されたのか、その理由を教えてください。私の理解では、「オープンポジションの 最大値」というような表現になるはずです。それ自体、トリガーする瞬間までの保留中の注文は、ここでは一切関係ないはずで、サーバーが(注文のトリガー時に)チェックすることを意味します。チャンピオンシップ規定を ご覧ください。サーバーは、保留中の注文のトリガーが何をもたらすか、つまりポジションを減らすか増やすかの拡張分析を実行することはありません。保留注文を出すために取引要求の一つ一つを解析していたら、サーバーに不当な負荷がかかってしまいます。 Правила Automated Trading Championship 2010 championship.mql5.com Правила Automated Trading Championship 2010 削除済み 2010.07.28 10:32 #674 Rosh:チャンピオンシップ規定を 参照。サーバーは、特定の保留中の注文のトリガーが、ポジションの減少または増加につながるかどうかの長時間の分析を実行することはありません。保留注文を出すために取引要求の一つ一つを解析していたら、サーバーに無理な負荷がかかってしまいます。注文がトリガーされたときにサーバーが集計位置を計算するのは、それほど難しいことではないと思ったのですが、間違っているのでしょうか......。自分で条件を確認しなければならないが...。追記この値を超えた場合、失格以外にどんな影響があるのか、また、サーバーはどんなエラーを返すのか(まあ、トレーダーやロボットが計算を間違えることはあるでしょうが)、知りたいものです。 Aleksey Lebedev 2010.07.28 10:39 #675 Rosh:チャンピオンシップ規定を 参照。サーバーは、特定の保留中の注文のトリガーが、ポジションの減少または増加につながるかどうかの長時間の分析を実行することはありません。仮に、保留中の注文を出すためにすべての取引要求を分析すると、サーバーに不当な負荷がかかることになります。 15ロットのポジションを建てた場合、sl/tpが発動するまで決済できないということでしょうか、それとも建玉方向が考慮されるのでしょうか。 Rashid Umarov 2010.07.28 10:43 #676 Interesting:注文がトリガーされたときに、サーバーが集計位置を計算するのは簡単だと思ったのですが、間違っていました......。 もう一歩踏み込んだ計算が必要です。トリガーがかかる瞬間のチェックを残すとしましょう。保留中の注文がトリガーされ、突然、最大取引量を超えていることが判明しました。どのような理由で拒否されるのでしょうか?最初から無駄な質問は排除したほうがいい。 Rashid Umarov 2010.07.28 10:48 #677 Swan: 15ロットのポジションを建てた場合、sl/tpが発動するまで決済できないということでしょうか、それとも建玉方向が考慮されるのでしょうか。 5ロットずつの連続した3回の成行注文で決済することができます。しかし、これは別のスレッドのための質問です、それはすでにそこに議論されている -自動売買選手権2010。 削除済み 2010.07.28 10:49 #678 Swan: 15ロットのポジションを建てた場合、sl/tpが発動するまで決済できないということですが、建てる際に方向は考慮されるのでしょうか?SLとTPは関係ないはずです。そして、どのような場合でも構築されているので、SLまたはTPのいずれかと見なされるべきである。これを閉じないと、SLとTPが明示的に書かれていない全てのアルゴリズムで、この制限に抵触した場合に発生するエラーが発生する可能性がありますね。追記だから、オープンポジション に限定することを提案したのです。 Aleksey Lebedev 2010.07.28 11:04 #679 Rosh: 5ロットずつの連続した3回の成行注文で決済することができます。しかし、これは別のスレッドのための質問です、それはすでにそこに議論されている -自動売買選手権2010。 はい、イノベーションの前に。しかし、あなたはヘルプから、任意の注文の方向が考慮されていないことを理解することができます) 削除済み 2010.07.28 11:07 #680 Rosh: もう一歩踏み込んで、トリガーとなる瞬間のチェックを残しておくと言う計算も必要です。保留中の注文がトリガーされ、突然、最大出来高を超えたことが判明しました。どのような理由で拒否されるのでしょうか?不要な質問はすぐに切り捨てたほうがいい。価格が注文に到達し、トリガーの瞬間が訪れるが、注文がマーケットに転送される前に、このルールに従って正しさをチェックする、というアルゴリズムをおおよそ想定しています。もし、このルールに反する操作を行った場合、2つの選択肢があります。1. - - オーダーを削除し、クライアントにエラーコードを 送信します (「all or nothing」ルールに従ってオーダーがトリガーされるべき場合)。2.- (all or nothing条件に該当しない場合)許容されたボリュームの取引を行い、残りのボリュームを最初のケースと同様にサーバーからの注文として削除する(エラーコードが表示される)。追記そうでなければ、リミットに達しているにもかかわらず、SLとTPを明示的に指定せずに操作を行った場合の対処法がわかりません。5 ロットずつのポジションを 3 つ持ち、そのうち 1 つを 5 ロットの反対注文で決済するとします。その結果、オーバーシュートが発生する。ボリューム<=14 ロットでオープンし、いずれかのポジションを部分的に(または完全に)クローズした場合、私が理解する限り、このルールは違反しないでしょう。 Документация по MQL5: Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений www.mql5.com Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений - Документация по MQL5 1...616263646566676869707172737475...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
こんにちは、CFD商品には制限があること、つまり注文の種類が SLとTPを除く日中であることを正しく理解しているかどうか助言してください。つまり、もし私が正しいのであれば、どのような関数を使えば、SLやTPを置くべきでないことを検出できるのでしょうか。ありがとうございました。
これらのキャラクターは、サーバー上で設定します。これは、ストップ・レベルを設定できないことを意味するものではありません。
取引日の終了後、保留中の注文は削除され、オープンポジションのストップレベルは保持されます。
この設定は、現時点ではMQL5から確認することはできません。
アカウント制限量
1シンボルにつきオープンポジションとペンディングオーダー(方向に関係なく)の最大許容合算量
二重
開発者に感謝 - 注文制限に感謝しますが、この場合、何が書いてあって、どう理解すべきなのかよくわかりません。:(
保留中の注文に関する部分に困惑しています。なぜここに追加されたのか、その理由を教えてください。
私の理解では、「オープンポジションの 合計の最大値」というような表現になるはずです。
このことは、それ自体、トリガーされる前の保留中の注文は、いかなる形でもここに関係すべきではなく、この条件の制御は、(注文がトリガーされた事実について)サーバーによって行われることを意味します。
追記
現在は0が 返され(制限がかかっていないという意味と受け止めています)、チャンピオンシップ期間中は15.0が 返されるはずです。そうだろうか?
アカウント制限量
1シンボルにつきオープンポジションとペンディングオーダー(方向に関係なく)の最大許容合算量
二重
開発者に感謝 - 注文制限に感謝しますが、この場合、何が書いてあって、どう理解すべきなのかよくわかりません。:(
保留中の注文に関する部分に困惑しています。なぜここに追加されたのか、その理由を教えてください。
私の理解では、「オープンポジションの 最大値」というような表現になるはずです。
それ自体、トリガーする瞬間までの保留中の注文は、ここでは一切関係ないはずで、サーバーが(注文のトリガー時に)チェックすることを意味します。
チャンピオンシップ規定を ご覧ください。
サーバーは、保留中の注文のトリガーが何をもたらすか、つまりポジションを減らすか増やすかの拡張分析を実行することはありません。保留注文を出すために取引要求の一つ一つを解析していたら、サーバーに不当な負荷がかかってしまいます。
チャンピオンシップ規定を 参照。
サーバーは、特定の保留中の注文のトリガーが、ポジションの減少または増加につながるかどうかの長時間の分析を実行することはありません。保留注文を出すために取引要求の一つ一つを解析していたら、サーバーに無理な負荷がかかってしまいます。
注文がトリガーされたときにサーバーが集計位置を計算するのは、それほど難しいことではないと思ったのですが、間違っているのでしょうか......。
自分で条件を確認しなければならないが...。
追記
この値を超えた場合、失格以外にどんな影響があるのか、また、サーバーはどんなエラーを返すのか(まあ、トレーダーやロボットが計算を間違えることはあるでしょうが)、知りたいものです。
チャンピオンシップ規定を 参照。
サーバーは、特定の保留中の注文のトリガーが、ポジションの減少または増加につながるかどうかの長時間の分析を実行することはありません。仮に、保留中の注文を出すためにすべての取引要求を分析すると、サーバーに不当な負荷がかかることになります。
注文がトリガーされたときに、サーバーが集計位置を計算するのは簡単だと思ったのですが、間違っていました......。
15ロットのポジションを建てた場合、sl/tpが発動するまで決済できないということでしょうか、それとも建玉方向が考慮されるのでしょうか。
15ロットのポジションを建てた場合、sl/tpが発動するまで決済できないということですが、建てる際に方向は考慮されるのでしょうか?
SLとTPは関係ないはずです。そして、どのような場合でも構築されているので、SLまたはTPのいずれかと見なされるべきである。これを閉じないと、SLとTPが明示的に書かれていない全てのアルゴリズムで、この制限に抵触した場合に発生するエラーが発生する可能性がありますね。
追記
だから、オープンポジション に限定することを提案したのです。
5ロットずつの連続した3回の成行注文で決済することができます。しかし、これは別のスレッドのための質問です、それはすでにそこに議論されている -自動売買選手権2010。
もう一歩踏み込んで、トリガーとなる瞬間のチェックを残しておくと言う計算も必要です。保留中の注文がトリガーされ、突然、最大出来高を超えたことが判明しました。どのような理由で拒否されるのでしょうか?不要な質問はすぐに切り捨てたほうがいい。
価格が注文に到達し、トリガーの瞬間が訪れるが、注文がマーケットに転送される前に、このルールに従って正しさをチェックする、というアルゴリズムをおおよそ想定しています。もし、このルールに反する操作を行った場合、2つの選択肢があります。
1. - - オーダーを削除し、クライアントにエラーコードを 送信します (「all or nothing」ルールに従ってオーダーがトリガーされるべき場合)。
2.- (all or nothing条件に該当しない場合)許容されたボリュームの取引を行い、残りのボリュームを最初のケースと同様にサーバーからの注文として削除する(エラーコードが表示される)。
追記
そうでなければ、リミットに達しているにもかかわらず、SLとTPを明示的に指定せずに操作を行った場合の対処法がわかりません。
5 ロットずつのポジションを 3 つ持ち、そのうち 1 つを 5 ロットの反対注文で決済するとします。その結果、オーバーシュートが発生する。
ボリューム<=14 ロットでオープンし、いずれかのポジションを部分的に(または完全に)クローズした場合、私が理解する限り、このルールは違反しないでしょう。