エラー、バグ、質問 - ページ 2179

新しいコメント
 
Nikolai Semko:

いいえ、ローディングとは関係ありません。

スタートバーをゼロにせず、50本とすれば、すべてOKです。瞬間的なものです。

そして、30気圧まで上げるとフリーズしてしまうのです。それ以降は、そうではありません。

絶対バグってる

これを試してみてください。

//+------------------------------------------------------------------+
//| Возвращает смещение бара по времени                              |
//| https://www.mql5.com/ru/code/1864                                |
//+------------------------------------------------------------------+
int iBarShift(const string symbol_name,const ENUM_TIMEFRAMES timeframe,const datetime time,bool exact=false)
  {
   datetime last_bar;
   if(!SeriesInfoInteger(symbol_name,timeframe,SERIES_LASTBAR_DATE,last_bar))
     {
      datetime array[1];
      if(CopyTime(symbol_name,timeframe,0,1,array)==1)
         last_bar=array[0];
      else
         return WRONG_VALUE;
     }
   if(time>last_bar)
      return(0);
   int shift=Bars(symbol_name,timeframe,time,last_bar);
   datetime array[1];
   if(CopyTime(symbol_name,timeframe,time,1,array)==1)
      return(array[0]==time ? shift-1 : exact && time>array[0]+PeriodSeconds(timeframe) ? WRONG_VALUE : shift);
   return WRONG_VALUE;
  }
//+------------------------------------------------------------------+
 
Artyom Trishkin:

これを試してみてください。

iBarShiftと何か関係があるのでしょうか？

標準のBars関数の バグについてです。

 
Nikolai Semko:

iBarShiftと何か関係があるのでしょうか？

標準のBars関数の バグについてです。

その関数もBars()を使用しています。iBarShift()のアナログでスタートしましたね。

 
Artyom Trishkin:

その関数もBars()を使用しています。あなたの場合、すべてはiBarShift()のアナログから始まっています。

はい、もちろん、iBarShiftのカウンターパートを使用すると、この問題が判明しました。

iBarShift関数はTFが1つしか使われていないので、このバグには該当しないでしょう。

また、CopyTime関数と Bars関数で 異なるTFを使用すると、このバグが発生します。

しかし、Barsはどんな時でも正常に動作するはずです。しかし、私の例は、iBarが数十秒間ハングアップする特殊なケースがあることを示しています。そして、それは歴史の読み込みとは関係ない。

 
Nikolai Semko:

はい、もちろん、iBarShiftのカウンターパートを使用すると、この問題が明らかになりました。

iBarShift関数はTFが1つしか使われていないので、このバグには該当しないでしょう。

また、CopyTime関数と Bars関数で 異なるTFを使用すると、このバグが発生します。

しかし、Barsはどんな時でも正常に動作するはずです。しかし、私の例は、iBarが数十秒間ハングアップする特殊なケースがあることを示しています。そして、それは歴史の読み込みとは関係ない。

これは、履歴の読み込みが原因である可能性が高い

 
Nikolai Semko:

はい、もちろん、iBarShiftのカウンターパートを使用すると、この問題が判明しました。

iBarShift関数はTFが1つしか使われていないので、このバグには該当しないでしょう。

また、CopyTime関数と Bars関数で 異なるTFを使用すると、このバグが発生します。

しかし、Barsはどんな時でも正常に動作するはずです。しかし、私の例は、iBarが数十秒間ハングアップする特殊なケースがあることを示しています。そして、それは歴史の読み込みとは関係ない。

要求された範囲にバーがない状況で、周期的な同期を試みているのだと思います。Barsは「正常に動作」しようと頑張っていますが、タイムアウトや同期試行回数で諦めているのだと思います。

そのような場合にBarsを呼び出さないように、自分で値を確認する必要があります。

 
Vitaly Muzichenko:

これは、履歴のアップロードが原因である可能性が高い

私はそうは思いません。22秒間、再びダウンロードされることはなかったはずだ。さらに、特別なインジケータですべてのTFの履歴を読み込ませています。

もしローディングだとしたら、最初の31本のバーにはローディングが必要で、次のバーには必要ないことをどう説明すればいいのでしょう。

 
Nikolai Semko:

もしサブローディングだとしたら、最初の31小節はサブローディングが必要で、その後の小節は必要ないことをどう説明するのでしょう。

ドキュメントより：指定された日付範囲のバーの 数を要求する場合、開始時間がその範囲に含まれるバーだけが考慮されます。

したがって、Bars()プロトタイプはゼロを返し、これはヒストリーがないと解釈され、スクリプトの場合の ::Bars() は、以前の投稿で正しく指摘されているように、タイムアウトまたは試行の失敗数によって終了する。

 
Kirill Belousov:

要求された範囲にバーがない場合、周期的な同期が試みられると思う - Barsは「正常に動作」しようと努力しており、タイムアウトまたは同期の試行回数によってあきらめる。

このような場合の理由は、自分で値を確認するためにBarsを呼び出してはいけないからです。

十分あり得ます。
でも、選択肢はたくさんあります。

バーというのは非常に重要な機能で、これがないと大変なんです。正確には、なくても大丈夫ですが、多大なリソースがかかります。

完璧に機能させる必要があります。

 
A100:

ドキュメントより: 指定された日付の範囲内でバーの数を 要求する場合、開店時間がその範囲内にあるバーだけが考慮されます。

したがって、Bars()プロトタイプは0を返し、これは履歴の欠如と解釈され、以前のメッセージで正しく指摘されたように、スクリプトはタイムアウトまたは失敗した試行の数によって終了する。

ゼロであることは明らかです。

そして、何 - 与えられた時間範囲内のバーがゼロと判断するのに22秒かかってもいいのでしょうか？

Barsの内部実装に明らかなアルゴリズム上のバグがあります。

この件に関しては、サービスデスクにリクエストを送るべきでしょう。週末を控えているので、月曜日にはこの件が分からなくなってしまうかもしれません。

1...217221732174217521762177217821792180218121822183218421852186...3185
新しいコメント