トレーディングにおける機械学習：理論、モデル、実践、アルゴトレーディング - ページ 297 1...290291292293294295296297298299300301302303304...3399 新しいコメント fxsaber 2017.03.27 16:48 #2961 匿名apply(embed(pattern, length(signal)), 1, cor, y = signal, method = 'pearson') ありがとうございます。こんな感じで、Rのカウントはどれくらいなんでしょうね。信号長1 000 000、パターン100 000でbiblaアルゴリズムを測定したところ、1秒間に1回の割合でした。 СанСаныч Фоменко 2017.03.27 19:35 #2962 fxsaber ありがとうございました。こんな感じで、Rのカウントはどれくらいなんでしょうね。信号長1,000,000、パターン100,000-1秒のバイブルアルゴリズムを測定しました。 100万倍速い!それがどうした？トレーディングシステムはプロセッサのように計測するのか？ fxsaber 2017.03.27 19:40 #2963 サンサニッチ・フォメンコ 100万倍速い!それで？トレーディングシステムはプロセッサのように計測される？ 何かコンプレックスがあるんでしょうね。 СанСаныч Фоменко 2017.03.27 19:47 #2964 fxsaber 何かコンプレックスがあるんでしょうね。 いいえ、コンプレックスではありません。 μlとRは全く別のシステムであり、重なり合うことはありません。そして、何を比較するのか？そして、あなただけではありません! fxsaber 2017.03.27 19:51 #2965 サンサニッチ・フォメンコμlとRは全く別のシステムであり、重なり合うことはありません。そして、何を比較するのか？そして、あなただけではありません!私は、どの言語でも珍しくない統計的タスクの実現速度にのみ興味がありました。Rは最もポピュラーな統計言語であり、多くのユーザが利用しています。だから、ここに比較の問題を置いたのです。実装のアルゴリズム、ひいてはその効率が気になるところです。どの言語で書かれているかは関係ありません。 СанСаныч Фоменко 2017.03.27 20:21 #2966 fxsaber私は、どの言語でも珍しくない統計タスクの実装速度にしか興味がありませんでした。Rは最もポピュラーな統計言語であり、ここでも多くの人が知っています。だからこそ、ここで比較の問題が問われるのです。実装のアルゴリズム、ひいてはその効率が気になるところです。何語で書かれているかは関係ない。MTはトレーディングターミナル です。そこで、私、このサイト、このスレッドで、TSの開発について議論しています。しかし、取引結果にはほとんど影響を与えないようなプログラミングのトリックを議論している人をいつも見かけるのです。相関関数自体は他のアルゴリズムでも有用である。この関数は取引決定ブロックに使用できますが（少なくとも私は使用しています）、取引シグナルの計算の主な時間は、mqlには全く存在しない、他の計算上複雑なアルゴリズムによって決まるため、その実行速度は全く意味を持ちません。それは、実行の段階での話です。TSの開発段階を考えると、Rはインタプリタであるため、例えば通貨ペアの相関を比較するなど、アルゴリズムが明確でなく、多くのバリエーションを試す必要がある段階で非常に有効であり、主にμlより優れています。Rでは、相関を確認する時間は、キーボードをノックすることで、初期ベクトルの形成など非常に便利な数行が表示されます。つまり、これらの関数と、一般にmclやRで実装されている他の関数の実行速度を比較するのは意味がない、というのが私の言いたかったことです。PS.でも、あなたのライブラリーのおかげでmcl5の勉強をせずに済みました、ありがとうございました。 fxsaber 2017.03.27 20:31 #2967 サンサニッチ・フォメンコMTはトレーディングターミナル です。そこで、私、このサイト、このスレッドで、TSの開発について議論しています。しかし、取引結果にはほとんど影響を与えないようなプログラミングのトリックを議論している人をいつも見かけます。実際、相関関数自体は他のアルゴリズムでも意味を持つので、ご質問の内容は同じです。従来は、アルゴリズムの性能の低さに阻まれ、TCで検証できないアイデアもありました。このケースでは、まさにそれが起こりました。代替アルゴリズムによって、オプティマイザーは、世界と同じくらい古い歴史を持ちながら、これまで妥当な時間で計算することができなかったアイデアを探求することができました。長さ数千のパターンで数千億のピアソンQCを計算しなければならない場合、一見単純に見える作業の低速化が克服しがたいボトルネックとなるのだ。もし、ある問題があまりにも計算量的に重く見えるなら、それは理解度の低い問題であると言い始めるかもしれない。おそらくそうなのでしょう。しかし、済んだことは仕方がない。そして、他の人がそのようなことをどのように実装しているかを見るのは、いつも興味深いことです。 Andrey Dik 2017.03.27 20:41 #2968 開発に少し時間をかけても、常に計算を速くするのがいいのか、それとも、開発を速くしても、常に計算が遅くなるのを我慢するのがいいのか？Rは開発が速いが計算が遅いとなると、どこで計算するのか？遅いスーパーカーを早く開発するため？そんなスーパーカーは必要ない。 anonymous 2017.03.27 20:46 #2969 fxsaber私は、どの言語でも珍しくない統計タスクの実装速度にしか興味がありませんでした。Rは最もポピュラーな統計言語であり、ここでも多くの人が知っています。だからこそ、ここで比較の問題が問われるのです。実装のアルゴリズム、ひいてはその効率が気になるところです。どの言語で書かれているかは関係ありません。 まあ、1000000長の信号と100000長のパターンでは、900001x100000の時間行列を作る必要があるので、この実装は妥当な時間でカウントされることは全くないでしょう :D でも、書くのに30秒もかからなかったので、ある程度のタスクサイズまではかなり応用が効くと思われます。fft/convolveで同じことができる。その場合、より多くのコードを書く必要があるが、Cのコードと同じように高速になる。Rでは、複雑なモデルのプロトタイプを作るのに非常に便利で、これがRの長所です。コードの性能は、スキルと経験が問われる。1.Rの構文やデータ型には 高速に動作するものがあります（mutable型とimmutable型（リストと環境）、forとlapply/sapply/など、S4とR6）。2.問題によってはRでの並列化が容易なため、他の言語＋計算で速いコードを書くよりも、遅いコードの解を早く得ることができます。3.言語における個々の操作は普遍的に行われるが、非効率的である。C++で小さくても計算量の多い関数を実装すれば、コード全体をC言語で書いた場合と同じように開発速度を落とさずに、驚異的な結果を得ることができる。 例えば、Rで行列の行や列の項目を合計する場合、rowSums/colSums/apply(, 1, sum)/apply(, 2, sum) と比べて4〜15倍速くなることがある。 fxsaber 2017.03.27 20:58 #2970 匿名 まあ、1000000長の信号と100000長のパターンでは、900001x100000の時間行列を作る必要があるので、この実装は妥当な時間内に全く計算できません :D でも、書くのに30秒もかからなかったので、ある程度のタスクサイズまではかなり応用が利くと思われます。fft/convolveで同じことができる。その場合、より多くのコードを書く必要があるが、Cのコードと同じように高速になる。Rは複雑なモデルのプロトタイピングに非常に適しており、そこが強みです。コードの速度は、技術と経験の問題です。1.Rの構成やデータ型には、他のものより高速なものがあります（mutable型とimmutable型（リストと環境）、forとlapply/sapply/など、S4とR6）。2.問題によってはRでの並列化が容易なため、他の言語＋計算で速いコードを書くよりも、遅いコードの解を早く得ることができます。3.言語における個々の操作は普遍的に行われるが、非効率的である。C++で小さくても計算量の多い関数を実装すれば、コード全体をC言語で書いた場合と同じように開発速度を落とさずに、驚異的な結果を得ることができる。 例えば、Rで行列の行や列の項目を合計すると、rowSums/colSums/apply(, 1, sum)/apply(, 2, sum) と比べて4～15倍速くなることがある。 詳しい回答ありがとうございましたいつも同じ問題、つまり自分の力量のなさです。 1...290291292293294295296297298299300301302303304...3399 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
apply(embed(pattern, length(signal)), 1, cor, y = signal, method = 'pearson')
ありがとうございました。こんな感じで、Rのカウントはどれくらいなんでしょうね。信号長1,000,000、パターン100,000-1秒のバイブルアルゴリズムを測定しました。
100万倍速い!それがどうした？トレーディングシステムはプロセッサのように計測するのか？
100万倍速い!それで？トレーディングシステムはプロセッサのように計測される？
何かコンプレックスがあるんでしょうね。
いいえ、コンプレックスではありません。
μlとRは全く別のシステムであり、重なり合うことはありません。そして、何を比較するのか？そして、あなただけではありません!
μlとRは全く別のシステムであり、重なり合うことはありません。そして、何を比較するのか？そして、あなただけではありません!
私は、どの言語でも珍しくない統計的タスクの実現速度にのみ興味がありました。
Rは最もポピュラーな統計言語であり、多くのユーザが利用しています。だから、ここに比較の問題を置いたのです。
実装のアルゴリズム、ひいてはその効率が気になるところです。どの言語で書かれているかは関係ありません。
私は、どの言語でも珍しくない統計タスクの実装速度にしか興味がありませんでした。
Rは最もポピュラーな統計言語であり、ここでも多くの人が知っています。だからこそ、ここで比較の問題が問われるのです。
実装のアルゴリズム、ひいてはその効率が気になるところです。何語で書かれているかは関係ない。
MTはトレーディングターミナル です。そこで、私、このサイト、このスレッドで、TSの開発について議論しています。しかし、取引結果にはほとんど影響を与えないようなプログラミングのトリックを議論している人をいつも見かけるのです。相関関数自体は他のアルゴリズムでも有用である。
この関数は取引決定ブロックに使用できますが（少なくとも私は使用しています）、取引シグナルの計算の主な時間は、mqlには全く存在しない、他の計算上複雑なアルゴリズムによって決まるため、その実行速度は全く意味を持ちません。
それは、実行の段階での話です。
TSの開発段階を考えると、Rはインタプリタであるため、例えば通貨ペアの相関を比較するなど、アルゴリズムが明確でなく、多くのバリエーションを試す必要がある段階で非常に有効であり、主にμlより優れています。Rでは、相関を確認する時間は、キーボードをノックすることで、初期ベクトルの形成など非常に便利な数行が表示されます。
つまり、これらの関数と、一般にmclやRで実装されている他の関数の実行速度を比較するのは意味がない、というのが私の言いたかったことです。
PS.
でも、あなたのライブラリーのおかげでmcl5の勉強をせずに済みました、ありがとうございました。
MTはトレーディングターミナル です。そこで、私、このサイト、このスレッドで、TSの開発について議論しています。しかし、取引結果にはほとんど影響を与えないようなプログラミングのトリックを議論している人をいつも見かけます。実際、相関関数自体は他のアルゴリズムでも意味を持つので、ご質問の内容は同じです。
従来は、アルゴリズムの性能の低さに阻まれ、TCで検証できないアイデアもありました。このケースでは、まさにそれが起こりました。代替アルゴリズムによって、オプティマイザーは、世界と同じくらい古い歴史を持ちながら、これまで妥当な時間で計算することができなかったアイデアを探求することができました。
長さ数千のパターンで数千億のピアソンQCを計算しなければならない場合、一見単純に見える作業の低速化が克服しがたいボトルネックとなるのだ。もし、ある問題があまりにも計算量的に重く見えるなら、それは理解度の低い問題であると言い始めるかもしれない。おそらくそうなのでしょう。しかし、済んだことは仕方がない。そして、他の人がそのようなことをどのように実装しているかを見るのは、いつも興味深いことです。
開発に少し時間をかけても、常に計算を速くするのがいいのか、それとも、開発を速くしても、常に計算が遅くなるのを我慢するのがいいのか？
Rは開発が速いが計算が遅いとなると、どこで計算するのか？遅いスーパーカーを早く開発するため？そんなスーパーカーは必要ない。
私は、どの言語でも珍しくない統計タスクの実装速度にしか興味がありませんでした。
Rは最もポピュラーな統計言語であり、ここでも多くの人が知っています。だからこそ、ここで比較の問題が問われるのです。
実装のアルゴリズム、ひいてはその効率が気になるところです。どの言語で書かれているかは関係ありません。
まあ、1000000長の信号と100000長のパターンでは、900001x100000の時間行列を作る必要があるので、この実装は妥当な時間でカウントされることは全くないでしょう :D でも、書くのに30秒もかからなかったので、ある程度のタスクサイズまではかなり応用が効くと思われます。fft/convolveで同じことができる。その場合、より多くのコードを書く必要があるが、Cのコードと同じように高速になる。
Rでは、複雑なモデルのプロトタイプを作るのに非常に便利で、これがRの長所です。コードの性能は、スキルと経験が問われる。
1.Rの構文やデータ型には 高速に動作するものがあります（mutable型とimmutable型（リストと環境）、forとlapply/sapply/など、S4とR6）。
2.問題によってはRでの並列化が容易なため、他の言語＋計算で速いコードを書くよりも、遅いコードの解を早く得ることができます。
3.言語における個々の操作は普遍的に行われるが、非効率的である。C++で小さくても計算量の多い関数を実装すれば、コード全体をC言語で書いた場合と同じように開発速度を落とさずに、驚異的な結果を得ることができる。 例えば、Rで行列の行や列の項目を合計する場合、rowSums/colSums/apply(, 1, sum)/apply(, 2, sum) と比べて4〜15倍速くなることがある。
まあ、1000000長の信号と100000長のパターンでは、900001x100000の時間行列を作る必要があるので、この実装は妥当な時間内に全く計算できません :D でも、書くのに30秒もかからなかったので、ある程度のタスクサイズまではかなり応用が利くと思われます。fft/convolveで同じことができる。その場合、より多くのコードを書く必要があるが、Cのコードと同じように高速になる。
Rは複雑なモデルのプロトタイピングに非常に適しており、そこが強みです。コードの速度は、技術と経験の問題です。
1.Rの構成やデータ型には、他のものより高速なものがあります（mutable型とimmutable型（リストと環境）、forとlapply/sapply/など、S4とR6）。
2.問題によってはRでの並列化が容易なため、他の言語＋計算で速いコードを書くよりも、遅いコードの解を早く得ることができます。
3.言語における個々の操作は普遍的に行われるが、非効率的である。C++で小さくても計算量の多い関数を実装すれば、コード全体をC言語で書いた場合と同じように開発速度を落とさずに、驚異的な結果を得ることができる。 例えば、Rで行列の行や列の項目を合計すると、rowSums/colSums/apply(, 1, sum)/apply(, 2, sum) と比べて4～15倍速くなることがある。