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

 
ユーリイ・アサウレンコ

そこが理解できないのです。なぜ、そのようなボリュームがRからMTに転送されなければならないのか?そして、そこで彼らをどうするか?

コンセプトが違うんです。MTからは必要な市場情報のみ、MTでは注文や取引のための情報。あとは、Jave、C++、Python、R、PHPなど、すべて利用可能です。

なぜ動物園を作る必要があるのか、理解できない。良い端末があれば、端末のタスクであるマーケットデータ、ビッド/トランザクションを解決しなければならないのです。

練習場でのNSの全予測を見て、チャートに転送して、NSから欲しいものを得たいのか、それとも何かでたらめを学習したのか、偶然にも歴史のある部分で利益が出ることがわかったのか、視覚的に確認したい場合です。
 
エリブラリウス
例えば、NSの予測結果をトレーニングエリアに表示し、グラフに転送して視覚的に推定することができます - NSから望むか、それは歴史の特定の部分で勝利しているいくつかのでたらめを学んだ。

なぜRではダメなのか?エクストラクラスのグラフィックを搭載しています。

 
エリブラリウス
例えば、あるトレーニングエリアでNSを予測したものをすべて表示し、チャートに転送して、NSから私が望むものを得たいか、それともNSがでたらめを学習し、それが偶然にも歴史の特定のセクションで利益をもたらすことが判明したかどうかを視覚的に評価することができます。

私の考えを変えようとしているのではありません。Rや他のモデリングソフトで同じことをするのは、もっと簡単です。さらに、すべてをすばやく変更したり、カウントしたり、追加のグラフやグラフの塊を表示したり、いくつかの統計を計算したりすることができます。しかも、これらすべてが文字通り5分以内。

MTでも、もちろんできますが、もっと大変で長いです。

 
サンサニッチ・フォメンコ

なぜRではダメなのか?エクストラクラスのグラフィックを搭載しています。

ユーリイ・アサウレンコ

あなたの考えを変えようとは思っていません。Rや他のモデリングソフトで同じことをするのは、もっと簡単です。また、グラフの変更、カウント、グラフの追加表示、統計計算なども可能です。しかも、これらすべてが文字通り5分以内。

MTでも、もちろんできますが、もっと大変で長いです。

端末ですべて見られる方が便利です。必要なバーの右側に矢印を付けることができます。拡大縮小やスクロールなど、すべてが可能になります。これだけ矢印が多いと見やすく描けないし、かといって100000個もあると端末が遅くなるし...。まあ、ウィンドウの見える部分だけに描いて、スクロール時に再描画すればいいんですけどね。

 
エリブラリウス

すべては端末で見る方が身近に感じられます。必要なバーの右側に矢印を付けることができます。拡大縮小やスクロールなど、すべてが可能になります。

最初は私もやっていたのですが、断念しました。何でもRの方が便利で、それらしくチャートもあるし、結果を分析するようになれば、いろいろと描けるようになります。端末の簡単なことでも、ものすごく苦労するんですよ。例えば、モデル適合度と見積もりとの差を描くために

 

ちなみに私は、少なくともソフトウェア開発においては、DLLを使うことを完全に諦めています。すべての情報は、テキスト(CSV)ファイルとRAM-Diskを介して、そこに戻ってくる。スカルピングパイピング>1.5Gb/sでも問題ない速度です。利点は、迅速な(数分)変更 - 転送チャネルに任意の情報を追加します。

そして、DLLは、すべての交換プロトコルが確立された後で、すでにすぐに使えるソフトウェアに対して行うことができます。

 
サンサニッチ・フォメンコ

最初は私もやっていたのですが、断念しました。何でもRの方が便利で、それらしくチャートもあるし、結果を分析するようになれば、いろいろと描けるようになります。端末の簡単なことでも、ものすごく苦労するんですよ。例えば、モデル適合度と見積もりとの差を描くために

これまでは松葉杖をついて、端末に出力する必要がありましたが、それができるようになりました。もっと高度なものが必要かもしれません。Rも使うかもしれませんが、私はRの初心者で、その長所をすべて知っているわけではありませんから。
 
サンサニッチ・フォメンコ

最初は私もやっていたのですが、断念しました。何でもRの方が便利で、それらしくチャートもあるし、結果を分析するようになれば、いろいろと描けるようになります。端末の簡単なことでも、ものすごく苦労するんですよ。例 えば、モデル適合度と見積もりとの差を描くために

+1

 
ユーリイ・アサウレンコ

ちなみに私は、少なくともソフトウェア開発においては、DLLの使用を完全にあきらめました。すべての情報は、テキスト(CSV)ファイルとRAM-Disk/を介してそこに戻る。 速度は、スキャルピングパイピング> 1.5Gb/sでも許容範囲です。9分という短時間で、あらゆる情報を転送チャンネルに追加できるのがメリットです。

また、DLLは、すべての交換プロトコルが確立された後、すぐに使えるソフトのために行うことができます。

エコノミーのためにバイナリー形式で可能です。でも、今あるものの代わりを開発する時間はないんです。他のアイデアも検証する必要がある...。どちらかというとチューニングでしょう)また、NSにあるものが金儲けのためにバウチャーされている場合は必要でしょう。
 
ユーリイ・アサウレンコ

ちなみに私は、少なくともソフトウェア開発においては、DLLを使うことを完全に諦めています。すべての情報は、テキスト(CSV)ファイルとRAM-Diskを介して、そこに戻ってくる。スカルピングパイピング>1.5Gb/sでも問題ない速度です。利点は、迅速な(数分)変更 - 転送チャネルに任意の情報を追加します。

そして、DLLは、すべての交換プロトコルが決着した後で、すでに既製のソフトウェアに対して行うことができます。

ファイルについて書くのは初めてではないんですね。

また、レディネス・ポーリングの問題はどのように解決されるのでしょうか。

理由: