トレーディングにおける機械学習:理論、モデル、実践、アルゴトレーディング - ページ 2947

 
Aleksey Nikolayev #:

とても良いことだ。ONNXのどのバージョンとオペセットがサポートされますか?

オープンソースのONNX Runtimeプロジェクトにあるものすべてです。

 
Renat Fatkhullin #:

これらはすべて、オープンソースのONNX Runtimeプロジェクトに含まれている。

onnx.defs.onnx_opset_version()は、opset=17と書いている。MTログのバージョンについては、1.14.0と書かれていますが、ONNXの最新バージョンは1.13.1だと思います。

 
Aleksey Nikolayev #:

onnx.defs.onnx_opset_version()はopset=17と書いている。MTログのバージョンについては1.14.0と書かれていますが、ONNXの最新バージョンは1.13.1のようです。

いいえ、その通りです。ONNXの 最新バージョンは1.13.1 、ONNXランタイムの最新バージョンは1.14.1です。

 
Renat Fatkhullin #:

チャート/ティック/取引ポジション/取引履歴にアクセスするための関数一式は上記の通りです。pythonスクリプトの直接的な作業にはこれで十分です。

おそらくインジケータへのアクセスも追加されるでしょう。

インジケータの転送は普遍的な方法ではありませんが、ほとんどのトレーダーにとっては十分でしょう。例えば、私はすべてのバーではなく、レベルがブレイクした瞬間にデータを転送することに興味があります。他のことに興味がある人もいる。

すべての人に合うような理想的な交換方法を作ることはほとんど不可能なので、開発段階での松葉杖的な方法は避けられません。主なことは、テスターやVPSでローンチする段階で松葉杖的な方法を避けることです。

 

新しいバージョンのMT5 b3601でONNX.Price.Predictionプロジェクトを テストしました。pythonでの学習と出力、MT5での出力(onnx用のdllをルートから削除し、ターミナルを再起動しました)、すべてがうまくいっているようです。

リリースを待って、独自のモデルで試してみることができます)

 
Aleksey Nikolayev #:

インジケータの送信は、ほとんどのトレーダーには十分ですが、普遍的な方法ではありません。例えば、私はすべてのバーではなく、レベルがブレイクした瞬間にデータを送信することに興味がある。他のことに興味がある人もいる。

すべての人に合う理想的な交換方法を作ることはほとんど不可能なので、開発段階での松葉杖的な方法は避けられません。主なことは、テスターやVPSで立ち上げる段階で、松葉杖的な方法を避けることである。

指標や任意のデータ(例えば文字列)をpythonに渡す問題は、MetaQuotesのビジネス利益に影響する。

これがすべて解決されれば、MTはブローカーとクライアントの仲介役から、ストラテジーやインジケーターを書くための便利なツールに変わります。

MTは相場を配信すると同時に、非常に高速で信頼性が高く、取引システムに組み込むのに最適な要素です。文字列をpythonに渡せるようにすることは、ターミナルのこの役割を強化することを意味する。

例えば、cryptoのブローカーは余分で不要な要素であるため、cryptoはMTをパスしましたが、Expert Advisorを書いたり使用したりするためのターミナルの使用をキャンセルするものではありません。

簡単に言うと、EAを書く⇒BTCUSDで実行する⇒Pythonスクリプト経由でBinanceで取引する⇒それができたことをMetaTraderに感謝する。

 

なぜONNXでこのようなことが必要なのか理解できません。


1.OnInit()からpythonスクリプトを別プロセスとして起動する。
2.pythonとEA間の情報交換のために、EAが情報を待つことができるモードで、いくつかの関数が必要である。
3.Modelsフォルダを作成し、TensorFlowモデルをそこに放り込む。

これで完了!MTとMOの統合が完了した!みんなハッピーだ。

 
Evgeny Dyuka #:

そもそも、なぜONNXで派手なことをするのか理解できない。



1.OnInit()から、pythonスクリプトを別プロセスとして起動する。 2.pythonとEAの間で、EAが情報の到着を待つことができるモードで、情報を交換するためのいくつかの関数が必要である。

これで完了!MTとMOの統合が完了した!みんなハッピーだ。

Rとの統合もある。ただ、なぜRがVPSに必要なのか、なぜMTとの統合をサポートするために問題が必要なのか(言語やパッケージのバージョン管理など)、がはっきりしない。pythonも同じだろう。

私たちのビジネスで非常に重要なスピードに関する点もある。fxsaberが、メタクォートとの絶え間ない戦いの中で、いかにミリ秒を削り、それが利益ポイントに変わるかを見てください。明らかに、何かと何かをバンドルしたものは、両方のプログラム単体よりも動作が遅くなる。

これ以上明白なことがあるだろうか......。

 
Aleksey Nikolayev プロジェクトを テストしました。python での学習と出力、MT5 での出力(ルートから onnx 用の dll を削除し、ターミナルを再起動しました)、すべてうまくいっているようです。

リリースを待って、独自のモデルで試すことができます。)

松葉杖が1本減り、使用モデルの幅が大きく広がる(これまでは、ターミナル入力でウェイトを最適化するのが主流だった)。どうやらマックでも動くはずなので、近いうちにチェックしてみる。
 
Aleksey Nikolayev #:

Rとのそのような統合はある。ただ、なぜVPSにRが必要なのか、なぜMTとの統合(言語やパッケージのバージョン管理など)をサポートするのに問題があるのかが明確ではない。pythonも同じだろう。

私たちのビジネスで非常に重要なスピードに関する点もある。fxsaberが、メタクォートとの絶え間ない戦いの中で、いかにミリ秒を削り、それが利益ポイントに変わるかを見てください。明らかに、何かと何かをバンドルしたものは、両方のプログラムを単独で実行するよりも遅くなる。

これ以上明白なことがあるだろうか......。


スプレッドや取引所・ブローカーの手数料を考慮すると、数十分あるいは数時間単位で予測する必要がある。50ミリ秒の差がどう関係するのでしょうか?
MQがfxsaberに5ミリ秒勝っていることが、実生活で具体的にどのように役立つのでしょうか?
理由: