記事「MetaTrader 5とMQL5経済指標カレンダー:ニュースを再現性のあるトレードシステムに変える方法」についてのディスカッション

 

新しい記事「MetaTrader 5とMQL5経済指標カレンダー:ニュースを再現性のあるトレードシステムに変える方法」はパブリッシュされました:

MetaTrader 5に組み込まれている経済指標カレンダーを利用したニューストレードの体系的アプローチを紹介します。対象となる内容には、データ構造、API関数、時間同期ルール、イベントフィルタリングが含まれます。また、サーバーへ過度な負荷をかけることなく履歴を管理するためのキャッシュ機構および増分更新方式についても解説します。さらに、同一アルゴリズムを用いた決定論的テストを実現するために、履歴データを.EX5リソースとしてエクスポートする実用的な仕組みも提供します。

現代のニューストレーダーが抱える主な問題は、ツールが分散していることと、アルゴリズムに基づく体系的な取引ワークフローが存在しないことです。ニュースサイトを閲覧するためのWebブラウザと、実際に取引をおこなうMetaTrader 5ターミナルの間で注意を切り替え続けるのは非常に困難です。

ニューストレーダーの一般的なワークフローは次のようになります。ニュースカレンダーを素早くブラウザで開き、イベントに変更がないか確認する → 直近のイベントを評価し、何をどのように取引するかを判断する → MetaTrader 5ターミナルへ移動し、保留注文(未決注文)を設定する、あるいはニュース発表を待ちながらリアルタイムで判断を下す。このような流れでは、トレーダーはしばしば「状況把握の途切れ」を経験します。その結果、ニュースへの反応が遅れ、最終的には損失につながります。

ニューストレードを、明確なルールと再現可能な結果、自動テストを備えた「工学的な課題」として扱いたいと思いませんか?本記事の目的は、MetaTrader 5向けニュースレイヤーの実用的なアーキテクチャを示すことです。具体的には、単一データソースの構築、カレンダーAPIの正しい利用方法、フィルタリングおよびキャッシュ機構、テスター向け履歴イベントのリソース化、ライブ環境とテスター環境の自動切り替えを扱います。


作者: MetaQuotes

 

記事、ありがとうございます。とても興味深いです。私自身は、wybコードとaiエージェントを使用して、ニュースやツイッターのパーサーを介して接続したいと思っていました。aiエージェントとのハイブリッドmql5も可能です。

 
Roman Shiredchenko #:

記事、ありがとうございます。とても興味深いです。私自身は、wybコードとaiエージェントを使用して、ニュースやツイッターのパーサーを介して接続したいと思っていました。aiエージェントとのハイブリッドmql5も可能です。

すべての詳細を含むvpisok全体がすでにターミナルにあるのに、なぜ何かを解析するのですか?はい、そしてii/aiもそこにあります)
 
Dmitriy Skub #:
すべての詳細を含むvpisok全体がすでにターミナルにあるのに、なぜ何かを解析するのですか?そう、そしてyi/aiもそこにある)

見ているだけでクールだ...。そしてバイブコードも...。)

 

執筆者

Если брокер учитывает переход на летнее/зимнее время — календарь автоматически подстраивается под этот переход

MQL5のAPIに何か変更があったのであれば教えてほしいのですが、以前はカレンダーはサマータイムを考慮して現在のタイムゾーンに調整されていました。つまり、夏の機能リクエストはUTC+3ゾーンのタイムスタンプを返しますが、冬の同じ履歴セクションのリクエストは、サーバーがサマータイムに切り替わるとUTC+2ゾーンのスタンプを持つイベントを取得します。したがって、6ヶ月以上のカレンダー履歴を正確にアップロードするには、ブローカーのタイムゾーン 変換履歴を分析する必要があります。詳細はコードベースにて

また、カレンダーキャッシュをリソースとしてリンクするアプローチはあまり実用的でないように思われ、特に、記事自体に記載されているエラー(EAの再コンパイルを忘れずに、など)を引き起こす。なぜ、すべてのエージェントで利用可能な Common フォルダにあるファイルとして、入力パラメータにカレンダーキャッシュを設定しないのでしょうか?

Economic Calendar Monitor and Cache for Backtesting on History
Economic Calendar Monitor and Cache for Backtesting on History
  • 2024.11.10
  • www.mql5.com
This indicator displays current events on the chart and allows you to export the calendar to archives for backtesting, automatically fixing time discrepancies between the history of bars and the history of events. This is an improved version of CalendarMonitorCached indicator from the algotrading book.
 
もしMQL5のAPIに変更があれば教えていただきたいのですが、以前はカレンダーはサマータイムを考慮した現在のタイムゾーンに調整されていました。つまり、夏の機能リクエストでは、例えばUTC+3ゾーンのタイムスタンプが返され、冬の同じ履歴セクションのリクエストでは、サーバーがサマータイムに切り替わると、UTC+2ゾーンのラベルのイベントが返されます。したがって、6ヶ月以上のカレンダー履歴を正確にアップロードするためには、ブローカーの転送履歴を分析する必要がある。 часового пояса ブローカーを使用する必要があります。詳細はコード ベースにある。

なぜ気配値(一般的にすべてのタイムスタンプ)はUTCで保存されないのですか?

なぜディーラーのティックは、1つの同じタイムリファレンスの異なる数値表現を持っているのですか?

哲学的な質問です :-) それは間違っているし、その場で問題を引き起こすが、それが行われている方法です。


ZЫ.だから、「歴史的なニュース」は他のソースから取った方がいい。

そして、決して「時計の翻訳の歴史を分析する」必要はない。それはすべてそこにある、それはOSまたはシステムライブラリの機能である。グーグルtzdata

自転車は何台作れるか?

 
Stanislav Korotky #:

以前は、カレンダーはサマータイムを考慮して現在のタイムゾーンに調整されていました。つまり、夏の機能リクエストでは、例えばUTC+3ゾーンのタイムスタンプが返され、冬の同じ履歴セクションへのリクエストでは、サーバーがサマータイムに切り替わったり戻ったりすると、UTC+2ゾーンのスタンプを持つイベントが返されます。

私も同じ考えです。
 
Maxim Kuznetsov #:


ZЫ.だから、「歴史的ニュース」は他のソースから取った方がいい。

そして、決して自分で「時計の翻訳履歴を分析」してはいけない。すべてそこにある、OSやシステムライブラリの機能なのだから。グーグルtzdata

自転車は何台作れるか?


他のソースでは、この問題は解決できない。なぜなら、MT5で引用符が保存される方法に埋もれているからだ。

まずはまっすぐな自転車を見せて、それからアドバイスをしてください。

 
MetaQuotes:

現代のニューストレーダーの主な問題は、断片的なツールセットと、体系的なアルゴリズム取引のワークフローの欠如である。インターネット・ブラウザ(ニュース・サイトの閲覧)と取引端末の間で注意を分散させながら取引を行うのはかなり難しい。

ニューストレーダーのワークフローは次のようなものだ:ウェブブラウザでニュースカレンダーを素早く開き、イベントの変更をチェックする → 今後のイベントを素早く評価し、何をどのように取引するかを決定する → MetaTrader 5ターミナルに移動し、未決注文を発注するか、ターミナルに座ってニュースリリースを待ち、決定を下す。このシナリオでは、トレーダーはしばしば文脈を見失い、ニュースへの反応の遅れにつながり、ひいては損失につながる。

明確なルール、再現可能な結果、自動化されたテストなど、ニュース取引をエンジニアリングの問題のように機能させたいとお考えだろうか?この記事の目的は、MetaTrader 5用のニュースレイヤーの動作アーキテクチャを実証することです:単一のデータソース、カレンダーAPIの適切な使用、フィルタリングとキャッシュのメカニズム、テスター用のリソースへのヒストリカルイベントのエクスポート、ライブとテスターの自動切り替え - 同じコードがリアルタイムとヒストリカルデータの両方で確定的な結果を生成するように。

そう、これはニュース取引にとって本当に悩ましい点だ。

ブラウザ、カレンダー、ターミナルを切り替えると、集中力が途切れて反応が遅くなる。ニュースを直接取引 環境に取り込む統一されたワークフローやシステムがあれば、執行がより速く、より一貫したものになるのは間違いない。

それをテストと自動化によって、構造化された再現可能な「エンジニアリング・スタイル」のセットアップに変えるというアイデアは、感情的な判断や遅れを避けるために、実に理にかなっている。