エラー、バグ、質問 - ページ 433 1...426427428429430431432433434435436437438439440...3185 新しいコメント 削除済み 2011.06.26 18:27 #4321 Renat さん、もしよろしければ、SRのアプリケーション#124661にご注目ください。6月13日から回答を待っています。 Renat Fatkhullin 2011.06.26 18:47 #4322 voix_kas:Renat さん、もしよろしければ、SRのアプリケーション#124661にご注目ください。6月13日から回答を待っています。だから、何度も正しい答えが返ってきたのですね。再度回答させていただきました。 削除済み 2011.06.26 19:15 #4323 Renat:だから、何度も正しい答えが返ってきたのですね。再度回答します。このアプリケーションには答えがない。その中の最後のコメントは2011.06.21 09:25の私のものです（質問の関連性を繰り返し念押し）。念のため、ここに複製しておきます。 取引/注文の最小量/ロットの制限は、ポジションを開く ときのみ関係するという理解で正しいですか？ ポジションの 閉鎖、増加、減少または逆転を もたらす取引/注文に 適用されるか？ 最低取引限度額は、上記の5つのシナリオのすべてに適用されます。 想定されるすべてのシナリオが記述されているようです。あるいは、この5つ以外のシナリオはあるのでしょうか？ Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок www.mql5.com Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок - Документация по MQL5 Renat Fatkhullin 2011.06.26 19:26 #4324 2回回答されたので、その後、回答しました。もう一度お答えします。はい、フルクローズは数量制限のルールの対象外です。 Renat Fatkhullin 2011.06.26 19:45 #4325 papaklass: MQL5の高速化ということでしょうか？ そう、コードの最適化とは、まさにそのことを意味するのです。 削除済み 2011.06.26 19:59 #4326 Renat:2回回答された後、私が回答しました。 もう一度お答えします。はい、フルクローズは数量制限のルールの対象外です。 レナート 誤解しないでください。甘やかすためではなく、明確にするために質問を繰り返す。 これまでのところ、あなたの回答やあなたの同僚の回答（SD）は、2つの シナリオをカバーしています：1）ポジションを開く、2）ポジションを完全に閉じる（おそらくORDER_FILLING_AONは 必須です）。 注文の執行（取引）は、少なくとも3つの 他の シナリオ（ポジションの 増加、減少、または反転）をもたらす 可能性があります。 残念ながら、この3つのシナリオについて、MQの回答には明確な 説明が見当たりません。:(わかりやすくするために、いくつかの例を示します（ サーバー上のすべてのケースで、最小ロット=1.0、最小ステップ=0.1です）。例1 （ポジション短縮）。 1.0のロングポジションを保有しています。ポジションを完全にクローズしようとしている（ORDER_FILLING_CANCEL を使用）。1.0ロットの売り注文を出します。注文は一部（0.9ロット）約定しました。 その結果、0.1ロットのオープンロングポジションが存在することになります。したがって、最小ロット数の要件は、ポジション・ショート・ シナリオには適用 されないと結論づけることができる。例2（立場逆転）。 0.1ロットのロングポジションを保有しています。0.2ロットの数量でサーバーに売り注文を出す。サーバーはこの注文を受け付けてくれるのでしょうか？(また最低敷地面積を満たしていない）。例3（ポジションの増加）。 0.1ロットのロングポジションを保有しています。0.1ロットの買い注文をサーバーに送りました。 Renat Fatkhullin 2011.06.26 20:11 #4327 voix_kas: 以下に例を示します（いずれも 最小ロット＝1.0、最小ステップ＝0.1）。例1 （ショートポジション）。 1.0ロットのロングポジションを保有しています。ポジションを完全にクローズしようとしている（ORDER_FILLING_CANCEL を使用）。1.0ロットの売り注文を出します。注文は一部（0.9ロット）約定しました。 その結果、0.1ロットのオープンロングポジションが存在することになります。したがって、最小ロット数の要件は、ポジション・ショート・ シナリオには適用 されないと結論づけることができる。ポジションの一部が0.9で決済された場合（1.0の注文あり）、0.1で残高を決済するために別の注文を出す必要があります。また、外部のゲートウェイで注文が執行された場合、1.0ロットのボリューム全体を一度に決済するだけで、分割はできない可能性が高いです。例2（立場逆転）。0.1ロットのロングポジションを保有しています。0.2ロットの数量でサーバーに売り注文を出す。サーバーはこの注文を受け入れるか？(また最低敷地面積を満たしていない）。 完全なゼロ清算ではないので、申請は却下されます。例3（ポジション量を増やす）。 0.1ロットのロングポジションを持っています。サーバーに0.1ロットの買い注文を出したのですが、このような注文のサーバーの例を教えてください。 もちろん、そんなことはありません。 ルールを文字通り読み、自分で条件を作ろうとしないでください。ルールは簡単で、「ポジションがゼロで清算される場合、数量制限ルールは適用されない場合がある」です。このルールは、何度も声を上げてきた。また、ブローカーや取引所のゲートウェイは、より厳しい独自のボリュームコントロールのルールを使用できることを考慮する必要があります。 削除済み 2011.06.26 20:28 #4328 なるほど、分かりやすい説明ありがとうございます。 Саша 2011.06.27 00:30 #4329 IlyaBukalov:開閉カッコが強調表示される最大行数は128行です。これは、1画面に収まらない開閉カッコを強調表示しても意味がないため、このような制限を設けたものです。また、この制限を導入したことで、MetaEditorの性能はかなり向上しました。 128個の文字列の後に括弧がハイライトされないと、括弧が閉じている場所を探すのに2、3画面 スクロールしなければならないことが多く、非常に不便です。 Andrey Khatimlianskii 2011.06.27 01:58 #4330 voix_kas:決定的な質問ではありませんが、それでも。文字列の連結。ドキュメントでは、StringAddと StringConcatenateの2つの関数について 説明されています。...結果2011.06.26 19:10:55 test (EURUSD,H1) №1 2012 ミリ秒, i = 10000000 2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 ミリ秒, i = 10000000 2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 ミリ秒, i = 10000000しかし、通常の足し算の方が速い ことが判明した。この例は誤りです。最初のメソッドでは、"result =result + string1 + string2 + string3;" とする必要があります。また、3つのテストが同じ条件で開始されないように、3つとも異なる結果になるようにします（一部のメモリはすでに割り当てられています）。さらに良いのは、テストを別々のスクリプトに入れ、それらを順次実行することです。こんな感じで持っています。1. 長さ = 10`000 2011.06.27 02:43:07 sStingTest (EURUSD,M1) №12542 ミリ秒, i = 10000 2011.06.27 02:43:05 sStingTest (EURUSD,M1) #20 ミリ秒, i = 10000 2011.06.27 02:43:05 sStingTest (EURUSD,M1) #30 ミリ秒, i = 10000 2. 長さ = 100`000 2011.06.27 02:37:40 sStingTest (EURUSD,M1) #247 ミリ秒, i = 1000000 2011.06.27 02:37:39 sStingTest (EURUSD,M1) #315 ミリ秒, i = 1000000 フィニッシュ #1 - 待たなかった 3. 長さ = 1`000`0002011.06.27 02:37:40 sStingTest (EURUSD,M1) #2780 ミリ秒, i = 10000002011.06.27 02:37:39 sStingTest (EURUSD,M1) #3187 ミリ秒, i = 10000001の終了は行われなかった。4. 長さ = 10`000`000 2011.06.27 02:48:14 sStingTest (EURUSD,M1) #31903 ミリ秒, i = 100000002回目のテストで「MemoryException: 602492946 bytes not available」エラーが発生しました。 結論：StringConcatenateが最速。ちなみに、StringAdd関数も、あまり正しい比較例では ありません。 それをテストするための私のコードは、トレーラーにあります。 ファイル: sStingTest.mq5 2 kb 1...426427428429430431432433434435436437438439440...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
Renat さん、もしよろしければ、SRのアプリケーション#124661にご注目ください。
6月13日から回答を待っています。
Renat さん、もしよろしければ、SRのアプリケーション#124661にご注目ください。
6月13日から回答を待っています。
だから、何度も正しい答えが返ってきたのですね。再度回答させていただきました。
だから、何度も正しい答えが返ってきたのですね。再度回答します。
このアプリケーションには答えがない。その中の最後のコメントは2011.06.21 09:25の私のものです（質問の関連性を繰り返し念押し）。
念のため、ここに複製しておきます。
取引/注文の最小量/ロットの制限は、ポジションを開く ときのみ関係するという理解で正しいですか？
ポジションの 閉鎖、増加、減少または逆転を もたらす取引/注文に 適用されるか？
最低取引限度額は、上記の5つのシナリオのすべてに適用されます。
想定されるすべてのシナリオが記述されているようです。あるいは、この5つ以外のシナリオはあるのでしょうか？
2回回答されたので、その後、回答しました。
もう一度お答えします。はい、フルクローズは数量制限のルールの対象外です。
MQL5の高速化ということでしょうか？
2回回答された後、私が回答しました。
もう一度お答えします。はい、フルクローズは数量制限のルールの対象外です。
レナート 誤解しないでください。甘やかすためではなく、明確にするために質問を繰り返す。
これまでのところ、あなたの回答やあなたの同僚の回答（SD）は、2つの シナリオをカバーしています：1）ポジションを開く、2）ポジションを完全に閉じる（おそらくORDER_FILLING_AONは 必須です）。
注文の執行（取引）は、少なくとも3つの 他の シナリオ（ポジションの 増加、減少、または反転）をもたらす 可能性があります。
残念ながら、この3つのシナリオについて、MQの回答には明確な 説明が見当たりません。:(
わかりやすくするために、いくつかの例を示します（ サーバー上のすべてのケースで、最小ロット=1.0、最小ステップ=0.1です）。
例1 （ポジション短縮）。
1.0のロングポジションを保有しています。ポジションを完全にクローズしようとしている（ORDER_FILLING_CANCEL を使用）。1.0ロットの売り注文を出します。注文は一部（0.9ロット）約定しました。
その結果、0.1ロットのオープンロングポジションが存在することになります。したがって、最小ロット数の要件は、ポジション・ショート・ シナリオには適用 されないと結論づけることができる。
例2（立場逆転）。
0.1ロットのロングポジションを保有しています。0.2ロットの数量でサーバーに売り注文を出す。サーバーはこの注文を受け付けてくれるのでしょうか？(また最低敷地面積を満たしていない）。
例3（ポジションの増加）。
0.1ロットのロングポジションを保有しています。0.1ロットの買い注文をサーバーに送りました。
以下に例を示します（いずれも 最小ロット＝1.0、最小ステップ＝0.1）。
例1 （ショートポジション）。
1.0ロットのロングポジションを保有しています。ポジションを完全にクローズしようとしている（ORDER_FILLING_CANCEL を使用）。1.0ロットの売り注文を出します。注文は一部（0.9ロット）約定しました。
その結果、0.1ロットのオープンロングポジションが存在することになります。したがって、最小ロット数の要件は、ポジション・ショート・ シナリオには適用 されないと結論づけることができる。
ポジションの一部が0.9で決済された場合（1.0の注文あり）、0.1で残高を決済するために別の注文を出す必要があります。
また、外部のゲートウェイで注文が執行された場合、1.0ロットのボリューム全体を一度に決済するだけで、分割はできない可能性が高いです。
例2（立場逆転）。
0.1ロットのロングポジションを保有しています。0.2ロットの数量でサーバーに売り注文を出す。サーバーはこの注文を受け入れるか？(また最低敷地面積を満たしていない）。
例3（ポジション量を増やす）。
0.1ロットのロングポジションを持っています。サーバーに0.1ロットの買い注文を出したのですが、このような注文のサーバーの例を教えてください。
もちろん、そんなことはありません。
ルールを文字通り読み、自分で条件を作ろうとしないでください。ルールは簡単で、「ポジションがゼロで清算される場合、数量制限ルールは適用されない場合がある」です。このルールは、何度も声を上げてきた。
また、ブローカーや取引所のゲートウェイは、より厳しい独自のボリュームコントロールのルールを使用できることを考慮する必要があります。
開閉カッコが強調表示される最大行数は128行です。これは、1画面に収まらない開閉カッコを強調表示しても意味がないため、このような制限を設けたものです。また、この制限を導入したことで、MetaEditorの性能はかなり向上しました。
決定的な質問ではありませんが、それでも。文字列の連結。ドキュメントでは、StringAddと StringConcatenateの2つの関数について 説明されています。
...
結果
2011.06.26 19:10:55 test (EURUSD,H1) №1 2012 ミリ秒, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 ミリ秒, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 ミリ秒, i = 10000000
しかし、通常の足し算の方が速い ことが判明した。
この例は誤りです。
最初のメソッドでは、"result =result + string1 + string2 + string3;" とする必要があります。
また、3つのテストが同じ条件で開始されないように、3つとも異なる結果になるようにします（一部のメモリはすでに割り当てられています）。
さらに良いのは、テストを別々のスクリプトに入れ、それらを順次実行することです。
こんな感じで持っています。
1. 長さ = 10`000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #20 ミリ秒, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #30 ミリ秒, i = 10000
2. 長さ = 100`000
2011.06.27 02:37:39 sStingTest (EURUSD,M1) #315 ミリ秒, i = 1000000
フィニッシュ #1 - 待たなかった
3. 長さ = 1`000`000
2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3187 ミリ秒, i = 1000000
1の終了は行われなかった。
4. 長さ = 10`000`000
2回目のテストで「MemoryException: 602492946 bytes not available」エラーが発生しました。
結論：StringConcatenateが最速。
ちなみに、StringAdd関数も、あまり正しい比較例では ありません。
それをテストするための私のコードは、トレーラーにあります。