MQL5でiClose/iOpenの時系列アクセスなどを操作した場合の不具合。 - ページ 10

 
fxsaber:

くだらない。

+1
 
fxsaber:

くだらない。

いきなり」(c)であれば、システムの性能に限界があることは問題ない(どっちでもいい)。

 

最近はOnCalculateとtickデータの処理について詳しく調べています。先ほど、不正に書かれたインジケータの「フリーズ」を避けるためにすべてを行うと書きましたが、もし本当に前回のOnCalculate呼び出し以降のティックデータフロー全体を処理したい場合、急激な値動き(およびロールバック)では、かなり「深い」配列が得られるはずですが、ティックの配列深さに何か制限があるのでしょうか?

OnCalculateは蓄積されたtick(s)を受け取り、最適化する...」といった回答は聞きたくないですね。

すでにティックデータを解析しているのは誰なのか、そんな心配は無用なのか。

 
Farkhat Guzairov:

最近はOnCalculateとtickデータの処理について詳しく調べています。先ほど、不正に書かれたインジケータの「フリーズ」を避けるためにすべてを行うと書きましたが、もし本当に前回のOnCalculate呼び出し以降のティックデータフロー全体を処理したい場合、急激な値動き(およびロールバック)では、かなり「深い」配列が得られるはずですが、ティックの配列深さに何か制限があるのでしょうか?

OnCalculateは蓄積されたtick(s)を受け取り、最適化する...」といった回答は聞きたくないですね。

すでにティックデータを解析しているのは誰なのか、そのような不安はないのか。

2008年から2009年にかけて、レナートはかつて「ダニに幸せはない」と書き、ある専門家を例に挙げた。ダニはとにかく飛ばす。必要な場合は、すべてのコールでhttps://www.mql5.com/ru/docs/series/copyticks、それでも入力するために望ましい50/50トップ/ボトムを逃す。

Документация по MQL5: Доступ к таймсериям и индикаторам / CopyTicks
Документация по MQL5: Доступ к таймсериям и индикаторам / CopyTicks
  • www.mql5.com
[in]  Количество запрашиваемых тиков. Если параметры from и count не указаны, то в массив ticks_array[] будут записаны все доступные последние тики, но не более 2000. Первый вызов CopyTicks() инициирует синхронизацию базы тиков, хранящихся на жёстком диске по данному символу. Если тиков в локальной базе не хватает, то недостающие тики...
 

宣伝のために、ここに書き込んでおきます。なぜこれが機能しなくなったのか、1ヶ月前から考えていました。

long lastbardaytime=0;

int OnInit(){ 
}

bool isNewBar(string symbol_,ENUM_TIMEFRAMES period_){
    long curbar = SeriesInfoInteger(symbol_,period_,SERIES_LASTBAR_DATE)%86400;
    if(lastbardaytime == 0){
        lastbardaytime = curbar;
    }
    if(lastbardaytime != curbar){
        lastbardaytime = curbar;
        return(true);
    }
    return(false);
}


void OnTick(){
    if(isNewBar(MIX-12.18,PERIOD_M1)){ 
        Print("New bar");
///....
    }
} 


オープニングの新作を待っています。

 

過去データの最適化および読み込みに関する質問を再開します。

1.iClose/iOpen機能、この場合はiTimeが正しく動作するという問題があり、すべてが完璧になることを期待するのは意味がないと思います。同じ過ちを繰り返さないために、単純にMQL5から削除すべきなのかもしれませんね。(問題があるのですが、それを説明する時間がありません。解決策、もうひとつの「ひねり」を見つけたからです)

もしかしたら解決策があるのかもしれませんが、またMQL5コミュニティのねじれではなく、文書化してほしいです。例えばローカルデータベースを同期させるような非同期リクエストにどう対処するかという話です。

インジケータでは、CopyTicks()関数は結果をすぐに返します。 インジケータから呼び出されると、CopyTick()はシンボルごとに利用可能なティックを直ちに返し、データが十分でない場合はティックデータベースの同期も開始します。1つのシンボル上のすべてのインジケータは1つの共通スレッドで動作するため、インジケータは同期の完了を待つ権利がありません。同期が完了すると、その後にCopyTicks()を呼び出すと、要求されたすべての目盛りが返されます。インジケーターのOnCalculate() 関数は、各ティックが着信した後に呼び出されます。


キーワードは「同期が終了したら、次にCopyTicks()を呼び出すと、要求されたすべてのティックが返さ れる」です。", 紳士たちよ、同期が終了したことをどうやって知ることができるのだ?同期 終了前にCopyTicks()が例えば-1を返すかのように書かれていますが、そうではありません。その結果、数回のリロードでインジケータDBが同期し、本当にデータセット全体を取得できているのですが、インジケータをリロードしていないと、このクソ同期を終えた結果が分からないので、データセットが取得できていないのです。

顕著な例としては、前回のノックで、EURUSDに急激な動きがあり、その間インジケータはずっとオンでこの期間を普通にレンダリングしていたが、リロード(入力パラメータ変更)した後、インジケータが情報を間違って反映し始め、それぞれインジケータのエラー検索を開始したが(何度もリコンパイルとリロードを行った)何も効果がなく、その後に「奇跡」が起こったことだ。"インジケータからCopyTick()を呼び出すと、シンボルで利用可能なティックを直ちに返し、またティックベースの同期を 開始します。" 多分、ローカルデータベースの同期が完了していないことを伝えることができる関数を作成(または持つ)べきで、この関数により我々の作業が容易になると、市場向けのより良い品質の製品を書くことができます。

追伸:SymbolInfoTick 関数には残念ながらこの 機能はありません。

 

残念ながら、この例はいつもうまくいくわけではありません。

//--- запросим тиковую историю с момента 1970.01.01 00:00.001 (параметр from=1 ms) 
      int received=CopyTicks(_Symbol,tick_array,COPY_TICKS_ALL,1,getticks); 
      if(received!=-1) 
        { 
         //--- выведем информацию о количестве тиков и затраченном времени времени 
         PrintFormat("%s: received %d ticks in %d ms",_Symbol,received,GetTickCount()-start); 
         //--- если тиковая история синхронизирована, то код ошибки равен нулю 
         if(GetLastError()==0) 
           { 
            success=true; 
            break; 
           } 
         else 
            PrintFormat("%s: Ticks are not synchronized yet, %d ticks received for %d ms. Error=%d", 
            _Symbol,received,GetTickCount()-start,_LastError); 
        } 

正確に言うと、10回中1-2回は効いています。

しかし、上記のような状況では、一度もうまくいきませんでした。

 

もう一度質問ですが、データベースはリアルタイムで更新されるのですか?

上に書いたように、問題のあった期間中はずっとインジケータが動作していた、つまりCopyTicks() 関数が 定期的に呼ばれていたのですが、結果的にローカルデータベースには何の効果も ありませんでした...。これはおかしいな...。

 
Unicornis:

2008年から2009年にかけて、レナートはある専門家の例を挙げて、「ダニに幸せはない」と書いたことがある。ダニはそのまま飛ばしています。必要であれば、すべてのコールでhttps://www.mql5.com/ru/docs/series/copyticks を取得しますが、それでもエントリーしたい50/50のトップ/トラフを逃すことになります。

しない人、必要な人 :) 実際のデータ、特にダニを持つことです。
 
Farkhat Guzairov:

最適化および過去データの読み込みに関する質問を再開します。

1.iClose/iOpen機能、そして今回のiTimeの正しい動作に関する問題はおそらく存在し、すべてが完璧になることを期待する理由はない。もしかしたら、同じ過ちを繰り返さないために、MQL5から単純に削除することができるかもしれません。(問題があるのですが、それを説明する時間がありません。解決策、もうひとつの「ひねり」を見つけたからです)

もしかしたら解決策があるのかもしれませんが、またMQL5コミュニティのねじれではなく、文書化してほしいです。例えばローカルデータベースを同期させるような非同期リクエストにどう対処するかという話です。

インジケータでは、CopyTicks()関数は結果をすぐに返します。 インジケータから呼び出されると、CopyTick()はシンボルごとに利用可能なティックを直ちに返し、データが十分でない場合はティックデータベースの同期も開始します。1つのシンボル上のすべてのインジケータは1つの共通スレッドで動作するため、インジケータは同期の完了を待つ権利がありません。同期が完了すると、その後にCopyTicks()を呼び出すと、要求されたすべての目盛りが返されます。インジケーターのOnCalculate() 関数は、各ティックが着信した後に呼び出されます。


キーワードは「同期が終了したら、次にCopyTicks()を呼び出すと、要求されたすべてのティックが返さ れる」です。", 紳士たちよ、同期が終了したことをどうやって知ることができるのだ?同期 終了前にCopyTicks()が例えば-1を返すかのように書かれていますが、そうではありません。その結果、数回のリロードでインジケータDBが同期し、本当にデータセット全体を取得できているのですが、インジケータをリロードしていないと、このクソ同期を終えた結果が分からないので、データセットが取得できていません。

顕著な例としては、前回のノックで、EURUSDに急激な動きがあり、その間インジケータはずっとオンでこの期間を普通にレンダリングしていたのですが、リロード(入力パラメータ変更)した後、インジケータが情報を間違って反映し始め、それぞれインジケータのエラー検索を開始(再コンパイル、リロードを数回)しましたが何も解決せず、あの「奇跡」が起きました。"インジケータからCopyTick()を呼び出すと、シンボルで利用可能なティックをすぐに返し ティックベースの同期も 開始します。" 多分、ローカルデータベースの同期が完了していないことを伝えることができる関数を作成する(または持つ)べきで、この関数によって我々の作業が容易になり、市場向けに優れた最終製品を書くことが可能になります。

追伸:SymbolInfoTick 関数には残念ながらこの 機能はありません。

このような場合、SERIES_SYNCHRONIZEDは何を返すのでしょうか?