for(int i=1; i<=OrdersTotal(); i++) // Цикл перебора ордер
{
if (OrderSelect(i-1,SELECT_BY_POS)==true) // Если есть следующий////Тут компенсируется отсутствие нуля с i-1
if (OrdersTotal()>0)
{ for (int i=OrdersTotal()-1; i>=0; i--)
{ if (OrderSelect(i,SELECT_BY_POS,MODE_TRADES)) // ордер выбирается среди открытых// и отложенных ордеров
{ if (OrderSymbol()!=Symbol()) continue; // если не наш символ, то уходимif (OrderMagicNumber()!=555) continue; // если не наш магик номер, то уходим// можно поставить любые другие фильтры// ... ваши вычисления
}
}
}
ところで、そうだ...この関数の全コードを上に追加済みです。
このように書かない方が論理的だと思ったからです。
というように、ループを設定します。
そうだろ?ただ、ゼロから何番目というカウンターがそう認識されていないだけで、論理的ではないので、混同する理由はないのですが......。
オーダーを探すには、1ではなく0にしなければならないのです。
以前、あるプロから「我々はオーダーの配列を検索しているのだから、大きい数字から検索したほうがいい」と説明されたことがあります。配列の最初の要素はインデックス0(ゼロ)なので、1には到達しないはずで、これが単純なOrdersTotal()ではなく、OrdersTotal()- 1に移行する理由でもあります。
オーダーサーチはこの方法でやってもらっています。
オーダーを探すには、1ではなく0にしなければならないのです。
以前、プロから「注文の配列だ」と説明され、それならそうだ、桁を大きくして始めた方がいいのでは?配列の最初の要素のインデックスは0(ゼロ)なので、1にはなりません。また、この理由から、OrdersTotal()だけでなく、OrdersTotal() - 1も必要です。
とても興味深いです。そして、まず最初にしたことは、教科書を開いて、そこから答えを探そうとすることでした。そして、https://book.mql4.com/ru/trading/ordermodify、チュートリアルがオーバーフローさせた様子を見た。
これが私を惑わせた要因です...。
とても興味深いです。そして、まず最初にしたことは、教科書を開いて、そこから答えを探そうとすることでした。そして、https://book.mql4.com/ru/trading/ordermodify、教科書のやり過ぎ感を目の当たりにしました。
それが惑わされた要因です...。
次の行に気がつかなかったのか?
次の行に気がつかなかったのか?
いや、しかし、なぜか書くと曲者である。教科書を批判するつもりはありませんが・・・-1より 0から 数えた方がよっぽど適切です。そうでなければ、すでに-30から スタートしていたかもしれないのに...。
上でpaladin80 さんが指摘されているように、-Nからよりも 0からの 方が配列の値が適切になるのではないでしょうか。
いや、しかし、なぜか書くと曲者である。教科書を批判するつもりはありませんが・・・-1より 0から 数えた方がよっぽど適切です。そうでなければ、すでに-30から スタートしていたかもしれない...。
上でpaladin80 さんが指摘されているように、0から なら配列の値、-Nから なら配列の値が最も適切でしょう。
さあ、論理的に考えよう!
i= 0なら、1からOrderTotal()まで、つまり、0+1からOrderTotal() - 1+1まで(i++が for文の最後にあるので+1)見る必要があるからです。チュートリアルでも同じですが、1からOrderTotal()までと書いてあるだけで、2からOrderTotal()+1まで数えないために、教科書著者はOrderSelect関数で iに-1をつけてますね、わかりますか。
ところで、プログラマーの数だけ、ほぼ同じ数のバリエーションが存在します。誰もが自分のビジョン、自分の筆跡を持っているのです
いや、しかし、なぜか書くと曲者である。教科書を批判するつもりはありませんが・・・-1より 0から 数えた方がよっぽど適切です。そうでなければ、すでに-30から スタートしていたかもしれないのに...。
上でpaladin80 さんが指摘されているように、配列の場合は-Nより 0の 方が適切でしょう。
オーダーの検索に興味があるなら、次のようなスキームを提案することができます。
いや、しかし、なぜか書くと曲者である。教科書を批判するつもりはありませんが・・・-1より 0から 数えた方がよっぽど適切です。そうでなければ、すでに-30から スタートしていたかもしれないのに...。
上でpaladin80 さんが指摘されているように、配列の読み方としては-Nではなく 0が 最も適切でしょう。
そして、今度はロジックも含めて考えてみてください
i= 0 の場合、1からOrderTotal()まで、つまり 0+1 から OrderTotal() - 1+1 (i++ が for 文の最後にあるので +1) まで試します。 そして、教科書にも同じように、1 から OrderTotal() までと、2 から OrderTotal()+1 までを数えないために OrderSelect 関数にi に-1 を追加します。 わかりましたか?
もちろん、クリアです。しかし、このような形でオーダーを分析したのは初めてです。
通常は==trueが ないだけです...この点については、好感が持てたくらいです。面白いのですが、他のEAではこのような手法に出会ったことがありませんでした。理屈はわかるけど、やっぱりね。
もちろん、わかっていますよ。ただし、オーダーの存在をこのように分析したのは初めてです。
通常は==trueが ないだけです...その点がよかったですね。面白いのですが、この方法は他のEAでは見たことがありません。理屈はわかるけど、やっぱりね。
いろいろなバリエーションで試してみると、すべてを理解しやすくなりますよ。がんばってください。