トレーディングにおける機械学習：理論、モデル、実践、アルゴトレーディング - ページ 298 1...291292293294295296297298299300301302303304305...3399 新しいコメント anonymous 2017.03.27 21:06 #2971 アンドレイ・ディク開発に少し時間をかけても常に素早く計算するのと、素早く開発しても常に計算が遅くなるのを我慢するのと、どちらがいいのでしょうか？Rで素早く開発しても、計算が遅いとしたら、どこで計算をするのか？運転が遅いスーパーカーの開発を急ぐ？そんなスーパーカーは必要ない。 研究課題では、開発スピードが前面に出てきます。超高速のコードを書きながら1日に1つの仮説を検証する人よりも、遅いコードを書きながら一晩中計算をし、翌日までに20の仮説を検証する人の方が、簡単に採用されます。モデルの生産・実装の ためには、最も有望なモデルを最速の言語で書き直してくれる人を、少額の給料でもう一人雇う方が簡単です。プログラマーはたくさんいて競争も激しいのですが、新しいことを考え出す研究者はなかなかいないんです :P当たり前のことなんですけどね。定量的研究者、定量的開発者としての仕事を探す。前者は通常R/Pythonを必要とし、後者は通常C++/Javaを必要とします。 Andrey Dik 2017.03.27 21:15 #2972 匿名 研究課題では、開発のスピードが前面に出てきます。超高速のコードを書いても、1日に1つの仮説をチェックする人ではなく、遅いコードを書いて一晩中動かしていても、翌日には20の仮説をチェックしている人を雇うことができるのです。モデルの本番実装には、わずかな給料でもう一人雇い、最も有望なモデルを早口言葉で書き換えてもらう方が簡単だ。プログラマーはたくさんいて競争も激しいのですが、新しいことを考え出す研究者はなかなかいないんです :P当たり前のことなんですけどね。定量的研究者、定量的開発者としての仕事を探す。前者は通常R/Pythonの知識が必要で、後者は通常C++/Javaの知識が必要です。高速開発」のために、同じでもRで遅いライブラリを使うより、準備ができていて速いC++のライブラリを使う方が簡単ではないでしょうか？あなただけでなく、ここにいる多くの人が、常に概念のすり替えを行っています。同じように、C言語的な環境でも「早く開発する」ことは可能です。あるいは、Rで仕事をするのに、データマイニングや統計学の適切な知識は必要ないのでしょうか？同じように、C言語で開発するための知識も必要です。では、なぜダブルワークなのか。それに、どんな「普段の練習」なのかわかりませんが、一回、一回でうまくやるのは慣れているんです。 エンジニアの実務の中で、なぜか「超ド級の開発しやすいソフト複合機を使えば、絶対にうまくいく」と思っている人をよく見かけました......。しかし、彼らはあることを理解できなかった。すべてがうまくいくためには、もうひとつ、頭の中の脂肪が必要なのだ。 anonymous 2017.03.27 22:15 #2973 アンドレイ・ディク： 高速開発」のために、同じでもRで遅いライブラリを使うより、既製品で高速なC++のライブラリを使う方が簡単ではないでしょうか？あなただけでなく、ここにいる多くの人が、常に概念のすり替えを行っています。同じように、C言語的な環境でも「早く開発する」ことは可能です。ライブラリについては、残念ながら、最新のアルゴリズムや変わったアルゴリズムについては、すべて自分で実装する必要があります。例えば、"bipower variance "を計算するためのライブラリ（どういう意味でしょうか？あるいは、Rで仕事をするのにデータマイニングや統計学の適切な知識は必要ないのでしょうか？私はそうは主張しないし、この意見を支持しない。それに、どんな「常識」があるのか知りませんが、一回、一回でうまくやるのは慣れていますよ。エンジニアの実務の中で、なぜか「超絶開発しやすいソフトを使えば、絶対にうまくいく」と思っている人をよく見かけました...。しかし、彼らはあることを理解できなかった。すべてがうまくいくためには、別のものが必要なのだ。それは、頭の中の脂肪である。私は、95%のコードがRで書かれた、人年単位の複雑なプロジェクトで 実践してきましたが、プロトタイプに使用し、生産に使用しない限り、異なるツールは異なるタスクに適しており、時には遅いタスクでさえも適していることがわかりました。開発段階でのツールの使い分けは、開発業界の常識であり、仕事によってスペシャリストが求められることでも確認されています。私が挙げたプロジェクトは、研究段階を経ずに、何でも知っていて、何でもできて、その解決策を一気に書き上げる万能兵士でも、C言語のような言語で実装したら、もっと複雑になっていたでしょう。というわけで、私はこれで失礼します。 СанСаныч Фоменко 2017.03.28 09:27 #2974 アンドレイ・ディク同じでもRで遅いものを使うより、既製品で速いC++のライブラリを使ったほうが「早く開発」できるのでは？Rを論じるとき、私は常にこの「グラフィックスと統計のシステム」を包括的、系統的に評価する立場に立っています。アルゴリズム言語そのものは、タイトルにはまったく書かれていません。特定のローカルな例について、Rのコードと上記のµlや他のプログラミング言語のコードの性能を正面から比較することは、全く正しくありません。なぜなら、TCは上記のように相関関数で構成されることはなく、常にコードと関数呼び出しからなる大きな集合だからです。Rには膨大な数の関数があるので、通常、コードの行数は少ないのですが（1000行は多い）、内容的には非常に容量が大きいのです。何らかの意味のある問題を解決するプログラムそのものは、大きく2つに分けられる。Rで書かれたコード形式のアルゴリズムRがシェルとなる関数の呼び出し。1について、もし相当量のコードを書かなければならないのであれば、スピードの問題は非常に深刻になります。それを克服する方法は3つあります。バイトコードに変換全コアおよび隣接するコンピュータへの並列化。これは標準的なもので、アルゴリズムが許せば非常に簡単にできます。コンパイル可能な他の言語への書き換え。C言語はRにネイティブであり、このような挿入のプロセスはよく文書化されている。2については、性能がかなり違うので、普段からμl-programの開発に特別な努力をしなければ、性能面でRを超えることはできないのではないでしょうか。例えば、こんな感じです。Rのベクトルや行列の演算は、表面的には基本的なものです。a <- b*c の形の式は、インテル・ライブラリーによって実行されます。ループはありません。誰でも利用でき、追加の知識や労力は必要ありません。μlのプログラムを開発する場合、サイクルを使用することがほとんどですが、同じライブラリを参照することも可能ですが（市場向けでない場合）、同じ結果を得るためにはかなり高度な知識と労力が必要です。しかし、それだけではありません。計算量の多いアルゴリズムを扱う場合、それがR関数へのアピールであれば、性能の問題に直面した開発者自身がこの問題に関心を持ち、通常は開発段階で解決してきたと思われる。これは通常、C言語のコードを書くか、CまたはFortranのライブラリを参照することで解決される。また、このようなアルゴリズムは、多くのコアを使用することをパラメータとして指定することが可能です。Rの開発者は、努力することなく、これらすべてを自動的に取得することができます。実装の技術ではなく、TCの本質に十分集中できる。μl-programの開発者がRの関数の開発者に勝てるかどうかは些細な理由であり、特に性能面では工夫が必要だが、TCの本質については工夫が必要ではない。以上のことから、正しい性能比較は、実際のTCコードをμl上で書き、同じコードをμl+R（Rには取引注文が ない）上で書いて比較することであることがわかります。しかし、その完全な栄光は、私たちに必要なものなのでしょうか？ Maxim Dmitrievsky 2017.03.28 10:48 #2975 mytarmailS: リカレンスプロットを使ってみた人はいますか？https://habrahabr.ru/post/145805/ に書いてあります。特に、生のBPの代わりにMOを代用する？ オプションとして機能するかもしれません。and more to readhttp://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf 実行できる人へのアイデア。マシンビジョンでは、これらのプロットを比較し、パターンマッチを探します。無駄な相関関係の代用として fxsaber 2017.03.28 10:51 #2976 マキシム・ドミトリエフスキー 実装できる方へのアイデアです。これらのプロットをマシンビジョンで比較し、パターンマッチを探します。無駄な相関関係の代用として。 ポン付けなしで最頻値のパターンを見つけることが可能です。しかし、何の意味があるのでしょうか？ Maxim Dmitrievsky 2017.03.28 10:52 #2977 fxsaber従来は、アルゴリズムの性能の低さに阻まれ、TCで検証できないアイデアもありました。このケースでは、まさにそれが起こりました。代替アルゴリズムによって、世界と同じくらい古い歴史を持ちながら、以前は妥当な時間で計算することができなかったアイデアを、オプティマイザで探索することができたのです。長さ数千のパターンで数千億のピアソンQCを計算しなければならない場合、一見単純に見える作業の低速化が克服しがたいボトルネックとなるのだ。もし、ある問題があまりにも計算量的に重く見えるなら、それは理解度の低い問題であると言い始めるかもしれない。おそらくそうなのでしょう。しかし、済んだことは仕方がない。そして、他の人が同じようなことをどのように実装しているかを見るのは、いつも興味深いことです。 また、GPUにも実装していただければ、本当に貴重な存在になると思います)) Maxim Dmitrievsky 2017.03.28 10:53 #2978 fxsaber ポンジがなければ、最も頻度の高いパターンを見つけることができます。しかし、何が言いたいのでしょうか？ もちろん、パターン・ストラテジーの場合、最も頻繁に使われるものとは限らず、多くのバリエーションがあるかもしれません。 fxsaber 2017.03.28 11:00 #2979 マキシム・ドミトリエフスキー パターンストラテジーの最も頻度の高いものとは限らず、多くのバリエーションが存在する可能性があります。これが理解できないのです。パターンデータの利用は、情報の損失が少ないデータ圧縮を行う場合に有効です（各種メディア）。しかし、それがTCとどう関係があるのでしょうか？このトピックを語るのに最も簡単な方法は、最も頻度の高いパターンを例に挙げることである。それを見つけるのは、決して難しいことではありません。ここでは、よく発生する謎解き（パターン）を紹介します。その選択基準は、今はそれほど重要ではありません。謎解きはそこそこに。トレードに使うには？一番外側の歴史が最初の80％のザガグリナと一致したら、次の価格は残りの20％のザガグリナと同じパターンになる、というのはナンセンスだ。 Maxim Dmitrievsky 2017.03.28 11:02 #2980 fxsaberこれが理解できないのです。パターンデータの利用は、情報の損失が少ないデータ圧縮を行う場合に有効です（各種メディア）。しかし、それがTCとどう関係があるのでしょうか？このトピックを語るのに最も簡単な方法は、最も頻度の高いパターンを例に挙げることである。探すのは難しいことではありません。ここでは、よく発生する謎解き（パターン）を紹介します。その選択基準は、今はそれほど重要ではありません。謎解きはそこそこに。トレードに使うには？一番外側の歴史が最初の8割のザガグリナと一致すれば、その後の価格は残りの2割のザガグリナと同じ道を歩むというのはナンセンスだ。 なぜ、ナンセンスだと思うのか。もし、同じ歴史の中で、大量のケースで、予測が確認されるのであれば。 1...291292293294295296297298299300301302303304305...3399 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
開発に少し時間をかけても常に素早く計算するのと、素早く開発しても常に計算が遅くなるのを我慢するのと、どちらがいいのでしょうか？
Rで素早く開発しても、計算が遅いとしたら、どこで計算をするのか？運転が遅いスーパーカーの開発を急ぐ？そんなスーパーカーは必要ない。
研究課題では、開発スピードが前面に出てきます。超高速のコードを書きながら1日に1つの仮説を検証する人よりも、遅いコードを書きながら一晩中計算をし、翌日までに20の仮説を検証する人の方が、簡単に採用されます。
モデルの生産・実装の ためには、最も有望なモデルを最速の言語で書き直してくれる人を、少額の給料でもう一人雇う方が簡単です。プログラマーはたくさんいて競争も激しいのですが、新しいことを考え出す研究者はなかなかいないんです :P
当たり前のことなんですけどね。定量的研究者、定量的開発者としての仕事を探す。前者は通常R/Pythonを必要とし、後者は通常C++/Javaを必要とします。
研究課題では、開発のスピードが前面に出てきます。超高速のコードを書いても、1日に1つの仮説をチェックする人ではなく、遅いコードを書いて一晩中動かしていても、翌日には20の仮説をチェックしている人を雇うことができるのです。
モデルの本番実装には、わずかな給料でもう一人雇い、最も有望なモデルを早口言葉で書き換えてもらう方が簡単だ。プログラマーはたくさんいて競争も激しいのですが、新しいことを考え出す研究者はなかなかいないんです :P
当たり前のことなんですけどね。定量的研究者、定量的開発者としての仕事を探す。前者は通常R/Pythonの知識が必要で、後者は通常C++/Javaの知識が必要です。
高速開発」のために、同じでもRで遅いライブラリを使うより、準備ができていて速いC++のライブラリを使う方が簡単ではないでしょうか？あなただけでなく、ここにいる多くの人が、常に概念のすり替えを行っています。同じように、C言語的な環境でも「早く開発する」ことは可能です。あるいは、Rで仕事をするのに、データマイニングや統計学の適切な知識は必要ないのでしょうか？同じように、C言語で開発するための知識も必要です。では、なぜダブルワークなのか。
それに、どんな「普段の練習」なのかわかりませんが、一回、一回でうまくやるのは慣れているんです。
エンジニアの実務の中で、なぜか「超ド級の開発しやすいソフト複合機を使えば、絶対にうまくいく」と思っている人をよく見かけました......。しかし、彼らはあることを理解できなかった。すべてがうまくいくためには、もうひとつ、頭の中の脂肪が必要なのだ。
高速開発」のために、同じでもRで遅いライブラリを使うより、既製品で高速なC++のライブラリを使う方が簡単ではないでしょうか？あなただけでなく、ここにいる多くの人が、常に概念のすり替えを行っています。同じように、C言語的な環境でも「早く開発する」ことは可能です。
ライブラリについては、残念ながら、最新のアルゴリズムや変わったアルゴリズムについては、すべて自分で実装する必要があります。例えば、"bipower variance "を計算するためのライブラリ（どういう意味でしょうか？
あるいは、Rで仕事をするのにデータマイニングや統計学の適切な知識は必要ないのでしょうか？
私はそうは主張しないし、この意見を支持しない。
それに、どんな「常識」があるのか知りませんが、一回、一回でうまくやるのは慣れていますよ。
エンジニアの実務の中で、なぜか「超絶開発しやすいソフトを使えば、絶対にうまくいく」と思っている人をよく見かけました...。しかし、彼らはあることを理解できなかった。すべてがうまくいくためには、別のものが必要なのだ。それは、頭の中の脂肪である。
私は、95%のコードがRで書かれた、人年単位の複雑なプロジェクトで 実践してきましたが、プロトタイプに使用し、生産に使用しない限り、異なるツールは異なるタスクに適しており、時には遅いタスクでさえも適していることがわかりました。開発段階でのツールの使い分けは、開発業界の常識であり、仕事によってスペシャリストが求められることでも確認されています。私が挙げたプロジェクトは、研究段階を経ずに、何でも知っていて、何でもできて、その解決策を一気に書き上げる万能兵士でも、C言語のような言語で実装したら、もっと複雑になっていたでしょう。
というわけで、私はこれで失礼します。
同じでもRで遅いものを使うより、既製品で速いC++のライブラリを使ったほうが「早く開発」できるのでは？
Rを論じるとき、私は常にこの「グラフィックスと統計のシステム」を包括的、系統的に評価する立場に立っています。アルゴリズム言語そのものは、タイトルにはまったく書かれていません。
特定のローカルな例について、Rのコードと上記のµlや他のプログラミング言語のコードの性能を正面から比較することは、全く正しくありません。なぜなら、TCは上記のように相関関数で構成されることはなく、常にコードと関数呼び出しからなる大きな集合だからです。Rには膨大な数の関数があるので、通常、コードの行数は少ないのですが（1000行は多い）、内容的には非常に容量が大きいのです。
何らかの意味のある問題を解決するプログラムそのものは、大きく2つに分けられる。
1について、もし相当量のコードを書かなければならないのであれば、スピードの問題は非常に深刻になります。それを克服する方法は3つあります。
2については、性能がかなり違うので、普段からμl-programの開発に特別な努力をしなければ、性能面でRを超えることはできないのではないでしょうか。
例えば、こんな感じです。
Rのベクトルや行列の演算は、表面的には基本的なものです。a <- b*c の形の式は、インテル・ライブラリーによって実行されます。ループはありません。誰でも利用でき、追加の知識や労力は必要ありません。μlのプログラムを開発する場合、サイクルを使用することがほとんどですが、同じライブラリを参照することも可能ですが（市場向けでない場合）、同じ結果を得るためにはかなり高度な知識と労力が必要です。
しかし、それだけではありません。
計算量の多いアルゴリズムを扱う場合、それがR関数へのアピールであれば、性能の問題に直面した開発者自身がこの問題に関心を持ち、通常は開発段階で解決してきたと思われる。これは通常、C言語のコードを書くか、CまたはFortranのライブラリを参照することで解決される。また、このようなアルゴリズムは、多くのコアを使用することをパラメータとして指定することが可能です。Rの開発者は、努力することなく、これらすべてを自動的に取得することができます。実装の技術ではなく、TCの本質に十分集中できる。μl-programの開発者がRの関数の開発者に勝てるかどうかは些細な理由であり、特に性能面では工夫が必要だが、TCの本質については工夫が必要ではない。
以上のことから、正しい性能比較は、実際のTCコードをμl上で書き、同じコードをμl+R（Rには取引注文が ない）上で書いて比較することであることがわかります。しかし、その完全な栄光は、私たちに必要なものなのでしょうか？
リカレンスプロットを使ってみた人はいますか？https://habrahabr.ru/post/145805/ に書いてあります。特に、生のBPの代わりにMOを代用する？ オプションとして機能するかもしれません。
and more to readhttp://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf
実行できる人へのアイデア。マシンビジョンでは、これらのプロットを比較し、パターンマッチを探します。無駄な相関関係の代用として
実装できる方へのアイデアです。これらのプロットをマシンビジョンで比較し、パターンマッチを探します。無駄な相関関係の代用として。
従来は、アルゴリズムの性能の低さに阻まれ、TCで検証できないアイデアもありました。このケースでは、まさにそれが起こりました。代替アルゴリズムによって、世界と同じくらい古い歴史を持ちながら、以前は妥当な時間で計算することができなかったアイデアを、オプティマイザで探索することができたのです。
長さ数千のパターンで数千億のピアソンQCを計算しなければならない場合、一見単純に見える作業の低速化が克服しがたいボトルネックとなるのだ。もし、ある問題があまりにも計算量的に重く見えるなら、それは理解度の低い問題であると言い始めるかもしれない。おそらくそうなのでしょう。しかし、済んだことは仕方がない。そして、他の人が同じようなことをどのように実装しているかを見るのは、いつも興味深いことです。
また、GPUにも実装していただければ、本当に貴重な存在になると思います))
ポンジがなければ、最も頻度の高いパターンを見つけることができます。しかし、何が言いたいのでしょうか？
もちろん、パターン・ストラテジーの場合、最も頻繁に使われるものとは限らず、多くのバリエーションがあるかもしれません。
パターンストラテジーの最も頻度の高いものとは限らず、多くのバリエーションが存在する可能性があります。
これが理解できないのです。パターンデータの利用は、情報の損失が少ないデータ圧縮を行う場合に有効です（各種メディア）。しかし、それがTCとどう関係があるのでしょうか？
このトピックを語るのに最も簡単な方法は、最も頻度の高いパターンを例に挙げることである。それを見つけるのは、決して難しいことではありません。
ここでは、よく発生する謎解き（パターン）を紹介します。その選択基準は、今はそれほど重要ではありません。謎解きはそこそこに。トレードに使うには？
一番外側の歴史が最初の80％のザガグリナと一致したら、次の価格は残りの20％のザガグリナと同じパターンになる、というのはナンセンスだ。
これが理解できないのです。パターンデータの利用は、情報の損失が少ないデータ圧縮を行う場合に有効です（各種メディア）。しかし、それがTCとどう関係があるのでしょうか？
このトピックを語るのに最も簡単な方法は、最も頻度の高いパターンを例に挙げることである。探すのは難しいことではありません。
ここでは、よく発生する謎解き（パターン）を紹介します。その選択基準は、今はそれほど重要ではありません。謎解きはそこそこに。トレードに使うには？
一番外側の歴史が最初の8割のザガグリナと一致すれば、その後の価格は残りの2割のザガグリナと同じ道を歩むというのはナンセンスだ。
なぜ、ナンセンスだと思うのか。もし、同じ歴史の中で、大量のケースで、予測が確認されるのであれば。