初心者の方からの質問 MQL5 MT5 MetaTrader 5 - ページ 643 1...636637638639640641642643644645646647648649650...1503 新しいコメント 削除済み 2016.10.14 07:19 #6421 Alexey Viktorov:リストの最後ではなく、時間的に「最年少」です。私も同じように気が利かないのですが。改造についての質問ですが、近くに書いている...また、単に修正するだけでは、注文のリストに穴があいてしまうので...。ただ、変数を追加して値を割り 当てる必要があるかもしれませんし、1番のエラーを回避するためにパラメータのチェックは必須です。まあ、ミラは自分でできるんですけどね。アルチョム・トリシキン並べ替えの依存性がなく、間違った順番をまったく見逃さないという のは、どうしたらいいのでしょうか？もう一度言いますが、最後の注文を確実に 見つけるためには、リスト上の位置ではなく、 開始時刻で 識別する必要があります。私の知る限り、リスト内の注文は早いもの(OrdersTotal()-1)から遅いもの(0)に向かって並んでいるだけです。もしそうでなく（リストは時間順にソートされていない）、証拠があるのなら、それを提示してください。もし、OrdersTotal()関数で履歴を要求した時点で、他のEAが注文を出したということであれば、それはスキップされるか（いずれにせよ、注文履歴に残る時間がないため）、注文リストの中で最新のものになります。もちろん、強く再確認して、total-1からすべての注文を開始する時間を0にすることもできますが、注文数や取引シンボルが多い場合には、最適解とは言い難いでしょう。 Artyom Trishkin 2016.10.14 07:30 #6422 Alexey Kozitsyn:私の知る限り、リスト内の注文は、単に最も古いもの（OrdersTotal()-1）から最も新しいもの（0）へとソートされます。もしそうでなく（リストは時間順にソートされていない）、証拠があるのなら、それを提示してください。もし、OrdersTotal()関数で履歴を要求した時点で、他のEAが注文を出したということであれば、それはスキップされるか（いずれにせよ、注文履歴に残る時間がない）、あるいは注文リストの最新のものとなる。もちろん、強く再確認して、total-1からすべての注文を開始する時間を0にすることもできますが、注文数や取引シンボルが多い場合には、最適解とは言い難いでしょう。なんだよ...その証拠に...。 mql4.comで昔からそういう状況が議論されていたのをあまり覚えていないんでしょうね。そこで、注文を時間で検索して、開閉時間を 一義的に判断した方が良いという結論に達しました。仕分けに依存があったというのは、もう繰り返しで飽きました。そして、仕分けに依存しないようにさせたのです。人々はリラックスして、あなたの言うとおりに行動するようになりました。そして、バッとまた仕分けに依存するようになった。人々は吠え、ロボットは狂い始めた。そして、再び仕分け依存症が解消された。いつかまた楽天のはずのものが潰れるという願望があるのなら、今のやり方でやればいいんです。しかし、そのような解決策を他人に提案するのはやめましょう。または、提供するとき、（検索）順番に、あなたとあなたのアルゴリズムに依存しない、リスト内のシンボルを並べ替えるに依存する必要な順序を、検索の失敗のためにお金を失うことの可能性をそれらに警告する。逆に言えば、あなたのアルゴリズムは他の誰かに依存しているのです...。販売店が開店・閉店の時間でごまかせるというのは内緒で、それは別の質問です。頑張ってください。 削除済み 2016.10.14 07:58 #6423 Artyom Trishkin:なんだよ...彼らが求める証拠... どうやら、昔、mql4.comでそのような状況が議論されたことをよく覚えていないようです。そこで、やはり注文の開閉 時間を一義的に決めるには、時間で検索した方が良いという結論に至ったのですね。仕分けに依存があったというのは、もう繰り返しで飽きました。それなら、そうならないようにしたんです。人々はリラックスして、あなたの言うとおりに行動するようになりました。そして、バッとまた仕分けに依存するようになった。人々は吠え、ロボットは狂い始めた。そして、再び仕分け依存症が解消された。いつかまた楽天のはずのものが潰れるという願望があるのなら、今のやり方でやればいいんです。しかし、そのような解決策を他人に提案するのはやめましょう。または、提供するとき、（検索）順番に、あなたとあなたのアルゴリズムに依存しない、リスト内のシンボルを並べ替えるに依存する必要な順序を、検索の失敗のためにお金を失うことの可能性をそれらに警告する。逆に言えば、あなたのアルゴリズムは他の誰かに依存しているのです...。まさか、ディーラーが開閉時間をごまかせるとは......それはまた別の問題です。頑張ってください。ああ、そんな議論は記憶にないな、4人組のフォーラムはあまり読んでないから。もしかしたら、昔々、そんなことがあったのかもしれません。しかし、「むかし」のものをすべて積み上げるのでは、どんなリソースも足りません。もし、いつかまた十字架を背負うという楽観的と思われる願望があるのなら、そのとおりにすればいいのです。しかし、そのような解決策を他人に提案するのはやめましょう。または、提供するとき、（検索）順番に、あなたとあなたのアルゴリズムに依存しない、リスト内のシンボルを並べ替えるに依存する必要な順序を、検索の失敗のためにお金を失うことの可能性をそれらに警告する。それどころか、あなたのアルゴリズムは、すべて他の誰かに依存しているのです...。おっしゃるとおり、他にもいろいろと「十字架を背負わされる」可能性はありますね。最後の注文を素早く判断する必要がある場合、時間内にすべてを検索するのは合理的ではありません。 私のやり方を受け入れるかどうかは、みなさんが自分で決めればいいことです。一番良い解決策は、多くの注文を出し、ソートがどのように機能するかを今すぐ確認することです。あなたも頑張ってください。 Aleksey Vyazmikin 2016.10.14 08:02 #6424 Artyom Trishkin:リストの最後の位置を見逃す確実な方法を示したということでしょうか？現実的なトレードをすると、急に仕分けが癖になりそうで不安じゃないですか？最初のサイクルでは、 開店時間までに 最も新しいポジションを探し、2番目のサイクルでは、最初のサイクルでチケットが見つかったもの以外をすべて変更します。いや、よくわからないが、論理的には正しい。MQの陰湿さについて以下を読みました - 不安が生じました。ご指摘ありがとうございます。 Artyom Trishkin 2016.10.14 08:08 #6425 Alexey Kozitsyn:最後の注文を素早く確認する必要があるときは、時間的に全部を確認するのは得策ではなく、その理由はすでに述べたとおりです。 なぜ、毎回通さなければならないのか？これこそが不合理なのです。マーケットポジションとクローズドオーダーを1ティックごとに検索し、構造体のすべてのフィールドに最後の2つのオーダー（オープンとクローズ）の必要なすべてのデータを入力することができます。そして、このティック中に得られたデータを利用する。このティックで変更した後、次のティックで2つの構造体の新しいデータと新しいフィールドを取得することになります。信頼性とスピードのバランスがとれているのでしょう。これが最適化というものです。そして、あなたが最適と呼ぶものは、IMHOでは、ハテナである ;) 削除済み 2016.10.14 08:18 #6426 Artyom Trishkin:なぜ、いちいち確認するのか？まさに合理的でない点です。マーケットポジションとクローズドオーダーを1ティックに1回検索し、構造体のすべてのフィールドに、直近の2つのオーダー（オープン、クローズ）の必要なデータを入力することができます。そして、そのティックのデータを使ってください。このティックで変更した後、次のティックで2つの構造体の新しいデータと新しいフィールドを取得します。信頼性とスピードのバランスがとれているのでしょう。これが最適化というものです。そして、あなたが最適と呼ぶものは、IMHOでは、ハテナである ;)細かいことを言うね、誰も毎回なんて言ってないのに。私もあなたと同じように、合理性には賛成です。ただ、それに対する考え方が違うだけです。 Artyom Trishkin 2016.10.14 08:25 #6427 Alexey Kozitsyn:ニュアンスになってる、誰も毎回なんて全く言ってないのに。私もあなたと同じように合理性には賛成です。ただ、あなたと私では合理性の捉え方が違うだけです。あなた自身の言葉。どこであれ、ラストオーダーを素早く決定する必要があるため、時間的にすべてのオーダーに目を通すのは合理的ではない、イミフ...。"どこでも "は、この文脈では "毎回 "と同義ではないのですか？だから「1ティックに1回通す」と言ったのです。構造のフィールドに正しいデータを記入し、毎回あちこちに通さずに、最後の注文に関するデータを取得する必要があれば、どこでもそれを使用することができます。私が間違って理解していたのかも？しかし、あなたの引用した表現は、IMHOは、理解の曖昧さを排除しています。 削除済み 2016.10.14 08:40 #6428 Artyom Trishkin:あなた自身の言葉。"どこでも "は、この文脈では "毎回 "と同義ではないのですか？それが私が答えた理由です。それは、1回のティックにつき1回、構造のフィールドに正しいデータを記入し、最後の注文に関するデータを得るために必要な場所で、毎回通過するのではなく、それを使用することです。もしかして、私が誤解しているのでは？しかし、あなたの引用した表現は、IMHOは、理解の曖昧さを排除しています。プログラム中に一時停止や単純に長い計算があり、その後に取引環境を更新しなければならないことを考慮していない。オーダーの配列をドラッグして移動するのは必ずしも便利ではなく、グローバル配列は必ずしも良い解決策ではありません。いずれにせよ、誰もあなたを非難しているわけではありませんが、あなたの選択肢が好ましくないケースもあるでしょう（多通貨・多注文システム）。また、MQが再びソート順を変更することに安心することは（mql4でもmql5でも同じであることを考えると）、必要ないことであると思います。 Artyom Trishkin 2016.10.14 09:11 #6429 Alexey Kozitsyn:プログラム中に一時停止や長い計算があり、その後に取引環境を更新する必要があることを考慮していないのでは？注文の配列を後ろにドラッグするのは必ずしも便利ではなく、グローバル配列は必ずしも良い解決策ではありません。いずれにせよ、誰もあなたを非難しているわけではありませんが、あなたの選択肢が好ましくないケースもあるでしょう（多通貨・多注文システム）。また、MQが再びソート順を変更することを再確認するために（mql4ではそうであり、mql5ではそうであることを考えると）、必要ないと思うのですが、いかがでしょうか。どんなキャラクターでも、どんなマジシャンでも、簡単に楽にデータを持つことができるクラスは、ずいぶん前に作られました。そして、特に全アレイを持ち運ぶ必要はなく、最後に開いたオーダーと最後に閉じたオーダーの2つだけを持ち運べばいいのです。毎回、長い計算や待ち時間の後、構造フィールドを再入力しなければならない、ところで、環境を更新しないのでしょうか？OKです。それは仕方がないことですが...。自分のやり方でやる。信頼性なんて気にするな、忘れろ...。 削除済み 2016.10.14 10:23 #6430 Artyom Trishkin:どんなシンボルでも、どんなマジシャンでも、簡単に、楽にデータを持つことができるクラスが出来て久しい。そして、特に配列全体をドラッグする必要はなく、last openedとlast closedの2つのオーダーだけです。毎回、長い計算や待ち時間の後、構造フィールドを再充填しなければならない、ところで、あなたは環境を更新しないのですか？OKです。大したことないんだけど...。自分のやり方でやる。信頼性なんて気にするな、忘れろ...。 そして、環境のアップデートはしています。ただ、検索方法に時間がかかるというだけで、信頼性については議論の余地があります。 1...636637638639640641642643644645646647648649650...1503 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
リストの最後ではなく、時間的に「最年少」です。
私も同じように気が利かないのですが。改造についての質問ですが、近くに書いている...また、単に修正するだけでは、注文のリストに穴があいてしまうので...。ただ、変数を追加して値を割り 当てる必要があるかもしれませんし、1番のエラーを回避するためにパラメータのチェックは必須です。まあ、ミラは自分でできるんですけどね。
並べ替えの依存性がなく、間違った順番をまったく見逃さないという のは、どうしたらいいのでしょうか？
もう一度言いますが、最後の注文を確実に 見つけるためには、リスト上の位置ではなく、 開始時刻で 識別する必要があります。
私の知る限り、リスト内の注文は早いもの(OrdersTotal()-1)から遅いもの(0)に向かって並んでいるだけです。もしそうでなく（リストは時間順にソートされていない）、証拠があるのなら、それを提示してください。
もし、OrdersTotal()関数で履歴を要求した時点で、他のEAが注文を出したということであれば、それはスキップされるか（いずれにせよ、注文履歴に残る時間がないため）、注文リストの中で最新のものになります。
もちろん、強く再確認して、total-1からすべての注文を開始する時間を0にすることもできますが、注文数や取引シンボルが多い場合には、最適解とは言い難いでしょう。
私の知る限り、リスト内の注文は、単に最も古いもの（OrdersTotal()-1）から最も新しいもの（0）へとソートされます。もしそうでなく（リストは時間順にソートされていない）、証拠があるのなら、それを提示してください。
もし、OrdersTotal()関数で履歴を要求した時点で、他のEAが注文を出したということであれば、それはスキップされるか（いずれにせよ、注文履歴に残る時間がない）、あるいは注文リストの最新のものとなる。
もちろん、強く再確認して、total-1からすべての注文を開始する時間を0にすることもできますが、注文数や取引シンボルが多い場合には、最適解とは言い難いでしょう。
なんだよ...その証拠に...。
mql4.comで昔からそういう状況が議論されていたのをあまり覚えていないんでしょうね。そこで、注文を時間で検索して、開閉時間を 一義的に判断した方が良いという結論に達しました。仕分けに依存があったというのは、もう繰り返しで飽きました。そして、仕分けに依存しないようにさせたのです。人々はリラックスして、あなたの言うとおりに行動するようになりました。そして、バッとまた仕分けに依存するようになった。人々は吠え、ロボットは狂い始めた。そして、再び仕分け依存症が解消された。
いつかまた楽天のはずのものが潰れるという願望があるのなら、今のやり方でやればいいんです。しかし、そのような解決策を他人に提案するのはやめましょう。または、提供するとき、（検索）順番に、あなたとあなたのアルゴリズムに依存しない、リスト内のシンボルを並べ替えるに依存する必要な順序を、検索の失敗のためにお金を失うことの可能性をそれらに警告する。逆に言えば、あなたのアルゴリズムは他の誰かに依存しているのです...。
販売店が開店・閉店の時間でごまかせるというのは内緒で、それは別の質問です。
頑張ってください。
なんだよ...彼らが求める証拠...
どうやら、昔、mql4.comでそのような状況が議論されたことをよく覚えていないようです。そこで、やはり注文の開閉 時間を一義的に決めるには、時間で検索した方が良いという結論に至ったのですね。仕分けに依存があったというのは、もう繰り返しで飽きました。それなら、そうならないようにしたんです。人々はリラックスして、あなたの言うとおりに行動するようになりました。そして、バッとまた仕分けに依存するようになった。人々は吠え、ロボットは狂い始めた。そして、再び仕分け依存症が解消された。
いつかまた楽天のはずのものが潰れるという願望があるのなら、今のやり方でやればいいんです。しかし、そのような解決策を他人に提案するのはやめましょう。または、提供するとき、（検索）順番に、あなたとあなたのアルゴリズムに依存しない、リスト内のシンボルを並べ替えるに依存する必要な順序を、検索の失敗のためにお金を失うことの可能性をそれらに警告する。逆に言えば、あなたのアルゴリズムは他の誰かに依存しているのです...。
まさか、ディーラーが開閉時間をごまかせるとは......それはまた別の問題です。
頑張ってください。
ああ、そんな議論は記憶にないな、4人組のフォーラムはあまり読んでないから。もしかしたら、昔々、そんなことがあったのかもしれません。しかし、「むかし」のものをすべて積み上げるのでは、どんなリソースも足りません。
もし、いつかまた十字架を背負うという楽観的と思われる願望があるのなら、そのとおりにすればいいのです。しかし、そのような解決策を他人に提案するのはやめましょう。または、提供するとき、（検索）順番に、あなたとあなたのアルゴリズムに依存しない、リスト内のシンボルを並べ替えるに依存する必要な順序を、検索の失敗のためにお金を失うことの可能性をそれらに警告する。それどころか、あなたのアルゴリズムは、すべて他の誰かに依存しているのです...。
おっしゃるとおり、他にもいろいろと「十字架を背負わされる」可能性はありますね。最後の注文を素早く判断する必要がある場合、時間内にすべてを検索するのは合理的ではありません。
私のやり方を受け入れるかどうかは、みなさんが自分で決めればいいことです。一番良い解決策は、多くの注文を出し、ソートがどのように機能するかを今すぐ確認することです。
あなたも頑張ってください。
リストの最後の位置を見逃す確実な方法を示したということでしょうか？
現実的なトレードをすると、急に仕分けが癖になりそうで不安じゃないですか？
最初のサイクルでは、 開店時間までに 最も新しいポジションを探し、2番目のサイクルでは、最初のサイクルでチケットが見つかったもの以外をすべて変更します。
いや、よくわからないが、論理的には正しい。
MQの陰湿さについて以下を読みました - 不安が生じました。ご指摘ありがとうございます。
最後の注文を素早く確認する必要があるときは、時間的に全部を確認するのは得策ではなく、その理由はすでに述べたとおりです。
なぜ、毎回通さなければならないのか？これこそが不合理なのです。
マーケットポジションとクローズドオーダーを1ティックごとに検索し、構造体のすべてのフィールドに最後の2つのオーダー（オープンとクローズ）の必要なすべてのデータを入力することができます。
そして、このティック中に得られたデータを利用する。このティックで変更した後、次のティックで2つの構造体の新しいデータと新しいフィールドを取得することになります。信頼性とスピードのバランスがとれているのでしょう。これが最適化というものです。そして、あなたが最適と呼ぶものは、IMHOでは、ハテナである ;)
なぜ、いちいち確認するのか？まさに合理的でない点です。
マーケットポジションとクローズドオーダーを1ティックに1回検索し、構造体のすべてのフィールドに、直近の2つのオーダー（オープン、クローズ）の必要なデータを入力することができます。
そして、そのティックのデータを使ってください。このティックで変更した後、次のティックで2つの構造体の新しいデータと新しいフィールドを取得します。信頼性とスピードのバランスがとれているのでしょう。これが最適化というものです。そして、あなたが最適と呼ぶものは、IMHOでは、ハテナである ;)
細かいことを言うね、誰も毎回なんて言ってないのに。私もあなたと同じように、合理性には賛成です。ただ、それに対する考え方が違うだけです。
ニュアンスになってる、誰も毎回なんて全く言ってないのに。私もあなたと同じように合理性には賛成です。ただ、あなたと私では合理性の捉え方が違うだけです。
あなた自身の言葉。
どこであれ、ラストオーダーを素早く決定する必要があるため、時間的にすべてのオーダーに目を通すのは合理的ではない、イミフ...。
"どこでも "は、この文脈では "毎回 "と同義ではないのですか？
だから「1ティックに1回通す」と言ったのです。構造のフィールドに正しいデータを記入し、毎回あちこちに通さずに、最後の注文に関するデータを取得する必要があれば、どこでもそれを使用することができます。
私が間違って理解していたのかも？しかし、あなたの引用した表現は、IMHOは、理解の曖昧さを排除しています。
あなた自身の言葉。
"どこでも "は、この文脈では "毎回 "と同義ではないのですか？
それが私が答えた理由です。それは、1回のティックにつき1回、構造のフィールドに正しいデータを記入し、最後の注文に関するデータを得るために必要な場所で、毎回通過するのではなく、それを使用することです。
もしかして、私が誤解しているのでは？しかし、あなたの引用した表現は、IMHOは、理解の曖昧さを排除しています。
プログラム中に一時停止や単純に長い計算があり、その後に取引環境を更新しなければならないことを考慮していない。オーダーの配列をドラッグして移動するのは必ずしも便利ではなく、グローバル配列は必ずしも良い解決策ではありません。
いずれにせよ、誰もあなたを非難しているわけではありませんが、あなたの選択肢が好ましくないケースもあるでしょう（多通貨・多注文システム）。また、MQが再びソート順を変更することに安心することは（mql4でもmql5でも同じであることを考えると）、必要ないことであると思います。
プログラム中に一時停止や長い計算があり、その後に取引環境を更新する必要があることを考慮していないのでは？注文の配列を後ろにドラッグするのは必ずしも便利ではなく、グローバル配列は必ずしも良い解決策ではありません。
いずれにせよ、誰もあなたを非難しているわけではありませんが、あなたの選択肢が好ましくないケースもあるでしょう（多通貨・多注文システム）。また、MQが再びソート順を変更することを再確認するために（mql4ではそうであり、mql5ではそうであることを考えると）、必要ないと思うのですが、いかがでしょうか。
どんなキャラクターでも、どんなマジシャンでも、簡単に楽にデータを持つことができるクラスは、ずいぶん前に作られました。そして、特に全アレイを持ち運ぶ必要はなく、最後に開いたオーダーと最後に閉じたオーダーの2つだけを持ち運べばいいのです。毎回、長い計算や待ち時間の後、構造フィールドを再入力しなければならない、ところで、環境を更新しないのでしょうか？
OKです。それは仕方がないことですが...。自分のやり方でやる。信頼性なんて気にするな、忘れろ...。
どんなシンボルでも、どんなマジシャンでも、簡単に、楽にデータを持つことができるクラスが出来て久しい。そして、特に配列全体をドラッグする必要はなく、last openedとlast closedの2つのオーダーだけです。毎回、長い計算や待ち時間の後、構造フィールドを再充填しなければならない、ところで、あなたは環境を更新しないのですか？
OKです。大したことないんだけど...。自分のやり方でやる。信頼性なんて気にするな、忘れろ...。