a が真であることが判明した場合、チェックは Array[over_index] に飛び、ここでターミナルは'array out of range' の部分でクラッシュし始めますが、これは全くその通りです。しかし、もしaがfalseになったら、端末はArray[over_index]の条件をチェックしないので、インデックスの冗長性をチェックせず、ifは さらにスキップして、コーダーは自分のプログラム中に存在しないインデックスを持つ配列があることを知らないままです...。というか、既存のものだけど冗長なもの。
もしかしたら、'array out of range' のチェックがif ループの最後まで行われ、同じメッセージが出力されるように修正する必要があるのでは?それとも、オペレーターのスピードが大幅に低下するのでしょうか?
は合計の後なので、端末は前の行を先に見て、過剰なインデックスを持つ配列があることを理解し、同じように'array out of range' のメッセージを出します。これが2つ目のことです。一つ目は、!h_plusではなく、ArraySize(high)<=i+incrementをチェックし、インデックスを超えたらループを脱出することです。昨日これだけやってみたが、微妙なところで失敗した。そう、メッセージはなかったが、インジケーターもぐちゃぐちゃになり始めたのだ。
は合計の後なので、端末は前の行を先に見て、過剰なインデックスを持つ配列があることを理解し、同じように'array out of range' のメッセージを出します。これが2つ目のことです。一つ目は、!h_plusではなく、ArraySize(high)<=i+incrementをチェックし、インデックスを超えたらループを脱出することです。昨日これだけやってみたが、微妙なところで失敗した。そう、メッセンジャーがいなくなっただけでなく、インジケーターもぐちゃぐちゃになりはじめたのだ。
a が真であることが判明した場合、チェックは Array[over_index] に飛び、ここでターミナルは'array out of range' の部分でクラッシュし始めますが、これは全くその通りです。しかし、もしaがfalseになったら、端末はArray[over_index]の条件をチェックせず、したがってインデックスの冗長性をチェックせず、ifは さらにスキップし、コーダーは自分のプログラムに存在しないインデックスを持つ配列があることを知らないでしょう...。というか、既存のものだけど冗長なもの。
もしかしたら、'array out of range' のチェックがif ループの最後まで行われ、同じメッセージが出力されるように修正する必要があるのでは? それとも、オペレーターのスピードが大幅に低下するのでしょうか?
即座に&=にしか答えられない。
MQL5 Reference Guide / Language Basics / Operations and Expressions / Assignment Operations:累積変数yになぞらえて
でも、&=は初めての経験なので、間違っているかもしれません。
まず、すべての論理条件をfor 内部の累積h_plusで合計し、その結果のbool-sumをfor 内部とは関係のないifに 挿入する。あなたの場合は、両方の条件を満たす必要があるため、この限りではありません。しかし、これを置くと
となると、そうですね。a "の条件が満たされた場合、2番目の条件はチェックされない。何年も前から争われてきたことなのに、前世紀に戻れというのか......。とはいえ...私のこの発言は間違っているのですが。どうやらここに書かれていることをよく理解していなかったようです。
あえてバグとは言いません。そんなわけで、if 演算子の一つの特殊性に気がついたとだけ言っておきます。他の書き言葉にも関係するのではないでしょうか。
a が真であることが判明した場合、チェックは Array[over_index] に飛び、ここでターミナルは'array out of range' の部分でクラッシュし始めますが、これは全くその通りです。しかし、もしaがfalseになったら、端末はArray[over_index]の条件をチェックしないので、インデックスの冗長性をチェックせず、ifは さらにスキップして、コーダーは自分のプログラム中に存在しないインデックスを持つ配列があることを知らないままです...。というか、既存のものだけど冗長なもの。
もしかしたら、'array out of range' のチェックがif ループの最後まで行われ、同じメッセージが出力されるように修正する必要があるのでは?それとも、オペレーターのスピードが大幅に低下するのでしょうか?
&&の条件と1つ目の条件が成立していなくても、2つ目の条件はチェックされません。というわけで、誤解を招いたのならお許しを...。
もう、その場の勢いでブレークも リターンも試して みましたが、事態は悪化するばかりでした。もう少しコードを簡略化して、breakで 考え直します...。
こんな感じ。
タイムラインに沿ってマウスを動かしてチャートを拡大縮小する場合、マウスの方向によってチャートが左右に動くため、ユーザーの視野にあるものがチャートの境界を越えて消えてしまうことがよくあります。そうすると、正しい場所を探さなければならないので、ひどく不便なのですが、これは私がMTに親しんでいるときからずっとそうでした。
虫眼鏡アイコンをクリックすれば、チャートが中央に再スケールされるのかと思いきや、そうではなく、マウスのスケーリングと同じように、チャートが左(圧縮)または右(拡大)に移動 する挙動を示します。
開発者の皆様へ我々は、チャートのスケーリング動作を変更することを切に求めます、それは、チャートの中心を残すことが必要である。
このチャートでの作業の不便さについては、相談した全員が賛成してくれているので、この問題を客観視することができます。
14年間、慣れようと思っても無理だった。
という感じです。
新鮮なアイデアですね、試してみます。
先の選択肢については
は、やってみなくても、もう明らかです。
は合計の後なので、端末は前の行を先に見て、過剰なインデックスを持つ配列があることを理解し、同じように'array out of range' のメッセージを出します。これが2つ目のことです。一つ目は、!h_plusではなく、ArraySize(high)<=i+incrementをチェックし、インデックスを超えたらループを脱出することです。昨日これだけやってみたが、微妙なところで失敗した。そう、メッセージはなかったが、インジケーターもぐちゃぐちゃになり始めたのだ。
先の選択肢については
は、やってみなくても、もう明らかです。
は合計の後なので、端末は前の行を先に見て、過剰なインデックスを持つ配列があることを理解し、同じように'array out of range' のメッセージを出します。これが2つ目のことです。一つ目は、!h_plusではなく、ArraySize(high)<=i+incrementをチェックし、インデックスを超えたらループを脱出することです。昨日これだけやってみたが、微妙なところで失敗した。そう、メッセンジャーがいなくなっただけでなく、インジケーターもぐちゃぐちゃになりはじめたのだ。
つまり、ここでの悩みは
i<rates_total-3
を書いたのには理由があり、ループの早い段階で追い出すのは、まさに if() の計算をシミュレートするためです。あえてバグとは言いません。そこで、if 文の特殊性に一つ気がついたことを述べておく。これは他の言語にも当てはまるのではないでしょうか。
a が真であることが判明した場合、チェックは Array[over_index] に飛び、ここでターミナルは'array out of range' の部分でクラッシュし始めますが、これは全くその通りです。しかし、もしaがfalseになったら、端末はArray[over_index]の条件をチェックせず、したがってインデックスの冗長性をチェックせず、ifは さらにスキップし、コーダーは自分のプログラムに存在しないインデックスを持つ配列があることを知らないでしょう...。というか、既存のものだけど冗長なもの。
もしかしたら、 'array out of range' のチェックがif ループの最後まで行われ、同じメッセージが出力されるように修正する必要があるのでは? それとも、オペレーターのスピードが大幅に低下するのでしょうか?
変数aをfalseに設定すると、制御が引き継がれ、配列やifの後の括弧内のコードには影響を与えません。
if(a && Array[over_index]>val) {...}
左の部分(a)が真である場合にのみ、右の部分の条件に制御が渡される
とすると
if(check(over_index) && Array[over_index]>val) {...}
チェック関数が配列の配列をチェックする場合、「配列が範囲外」ということはあり 得ません。 そこで、配列のインデックスをチェックし、それを1つのifで扱うことができます。 しかし、最初の部分が偽の場合、&&オペレータで次の部分に制御を移すことは、既存のどのプログラミング言語でもほとんど不可能です...。
ひとつ問題があって、それはランダムに、ときどき現れることです。
テスターで複数の通貨で作業していると表示される。
各サイクルでは、シンボルの実勢価格を要求しています。何らかの理由で特定のシンボルの相場を受信できなかった場合、別のシンボルについて以前に取得した相場を使用します。
指定した価格より高ければ、ポジションを建てるべきですね。他のシンボルから間違ったデータを取得した場合、ポジションをオープンする必要があります。
価格が1.45117より上にある場合、EURCADシンボルが開きます。1.74425>1.45117? はい、高いですが、他のシンボルの価格です。
500件中、7件の誤発注を検出しました。
ひとつ問題があって、それはランダムに、ときどき現れることです。
テスターで複数の通貨を使用して作業しているときに表示されます。
各サイクルでは、シンボルの実勢価格を要求しています。何らかの理由で特定のシンボルの相場を受信できなかった場合、別のシンボルについて以前に取得した相場を使用します。
指定した価格より高ければ、ポジションを建てるべきですね。オープニングに他のシンボルの間違ったデータを使っています。
EURCAD記号 価格が1.45117より上にある場合、それは開きます。1.74425>1.45117? はい、高いですが、他のシンボルの価格です。
500件中、7件のエラーオーダーを検出しました。
問題はコードにあるのですが、テレパスはすでに祝杯をあげており、眠りから覚めると、「エラーは123652行目にある」と言い出します。
コードに問題があるが、テレパスはすでに祝杯をあげており、暴飲暴食から抜け出したら、「エラーは123652行目にある」と言い出すだろう
コードにエラーがない、エラーをなくすためにコードを書き直した、エラーが定期的に出るわけではない、完全にカオスである