ライブラリ: カレンダー

 

カレンダー:

カレンダー - 歴史とリアルタイムのファンダメンタル分析。

カレンダー

Author: fxsaber

 
マエストロは土台を引き受けた。ブラボー!素晴らしい変化がやってくる :)
 
Aleksey Mavrin:
マエストロは土台を引き受けた。ブラボー!大きな変化がやってくる :)

まだ何も来ていない。図書館だ。

 
最初の公開時、ソースコードに誤ってゴミが入ってしまった。コードを更新した。
 
私自身は、リマインダーとして使っている。
#include <fxsaber\Calendar\Calendar.mqh> // https://www.mql5.com/ja/code/32430

int OnInit()
{
  return(!EventSetTimer(1));
}

void OnTimer()
{
  CALENDAR Calendar;
  
  string Currencies[2];
  
  // 現在の文字の通貨を取得します。
  Currencies[0] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_BASE);
  Currencies[1] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_PROFIT);
    
  // 今後の重要なイベントをシンボル通貨で表示します。
  Calendar.Set(Currencies);
  
  Comment(Calendar.ToString(0, 5, true)); // プリントアウトした。
}

重要なニュースを見逃す可能性が大幅に減った。


このようなゼロからのハチェット・コールは0.6ミリ秒以内に実行される。もちろん、消費をゼロにすることも可能である。

 

イベントのカレンダーは、ずっと先の未来まで書き込まれます。そのため、MT5のデータからファイルを保存することで、MT4でもリマインダーを使うことができます(たとえば1ヶ月先)。

これは私がMT4でやっていることです。

 
IMHOでは、より詳細なドキュメントがまだ不足している。コードを調べることができるのは確かだが、それなら他人のコードを分析する代わりに自分のコードを書けばいい;-)。特に、最初にSetを行わずにGetを呼び出せるのか、フィルタをロールバックできるのか(私が理解する限りではできない)、は不明です。特に、私の理解が正しければ、TimeCurrentの 発生ではなく、change_idを比較すべきです。データの更新がイベントの開始と正確に一致するとは限らないからです。
 

Stanislav Korotky:
ИМХО, все же не хватает более подробной документации. Понятно, что можно заглянуть в код, но тогда вместо разбирания в чужом коде можно и свой написать ;-).

mqhの中でALT+Mを押す。メソッドの名前は意味があるようだ。

特に、Setを実行せずにGetを呼び出すことができるのか、フィルタをロールバックできるのか(私が理解する限り、ロールバックはできない)については不明である。

Set - オブジェクトをイベントで満たします。これへのアクセスは、配列の要素に アクセスするようなものだ。

特に、私の理解が正しければ、データの更新がイベントの開始と正確に一致するとは限らないので、TimeCurrentの発生ではなく、change_idを比較する必要があります。

バックテストについて話しているのであれば、change_idは存在しないし、存在し得ない。

リアルタイムに関しては、この機能はライブラリのもう少し後に追加される予定です。


フィルターのロールバックは他と同じで、フィルター前のオブジェクトのコピーを作成する。

 

アーキテクチャ的には、パーサーの形で他のデータソースを埋め込むことができるように作られています。この目的のためにEVENT::Sourceフィールドもあり、これは現在ただ一つの値 "MetaTrader5 "に等しい。

つまり、カレンダーをスタックする機能がある。複数のソースからデータを取得し、それらを1つの場所に結合したと仮定します。

 
fxsaber:

バックテストについて話しているのであれば、change_idは存在しないし、存在し得ない。

これは疑わしいニュアンスである。現実の世界ではイベントが変更される可能性があり、テスターが(ライブラリを通じて)変更の履歴を再現しなければ、テストの妥当性は落ちる。同じような話題は、ここでもすでにいくつかのスレッドで触れられている:あるイベントのオンライン指標が同じで、その後修正される。補正された値を使ってテストしても、専門家が「その場で」分析したような画像は得られない。さて、あるいは私はアップデートへのアクセスについて誤解していました。

 
Stanislav Korotky:

これは疑問の残るニュアンスである。現実の世界では出来事が変化することがあり、(ライブラリを通じて)テスターが変化の履歴を再現しなければ、テストの妥当性は低下する。同じようなトピックは、いくつかのスレッドですでに触れられている:あるイベントのオンライン指標が同じで、その後修正される。補正された値を使ってテストしても、専門家が「その場で」分析したような画像は得られない。さて、あるいは私はアップデートへのアクセスについて誤解していました。

カレンダーには、各イベントに対して4つの値が含まれている:

  • 現在(実際) - ニュースリリース後、最初に受信した値。
  • 予測値 - ニュースが発表される前に(誰によって)予測された値。
  • 前回 - 前回、同じカレンダーのニュースが発表された後、最初に受信された値。すなわち、前回のActualと等しい:Previous[i] = Actual[i - 1]。
  • 修正値 - 前回の Actual の修正値。この更新の時間(と回数)は、カレンダーには保存されない。

すべての HTML カレンダー(標準カレンダーと ターミナルを含む)では、トリプル (Actual, Forecast,Previous) = (Actual, Forecast,Revised) です。そのため、次に関連するイベントが発生するまで、履歴で改訂フィールドを使用することはできません。他は使用できます。

Actual の受信ラグ値、より正確には、特定の取引サーバーとニュース・ソースの非同期性に関する情報はない(ありえない)。これがバックテストで考慮されない理由です。このニュアンスは明らかです。


以上のことを考慮すると、TimeTradeServer をバックテストのイベント時刻と比較することは全く正当である。そして、イベント直前の(前回、予測、修正)、直後の (実際、予測、前回)を使用します