トレーディングにおける機械学習：理論、モデル、実践、アルゴトレーディング - ページ 665 1...658659660661662663664665666667668669670671672...3399 新しいコメント Mykola Demko 2018.02.11 13:59 #6641 ウラジミール・ペレヴェンコまったくもって、正しいアプローチです。今のところ、絶対に間違ったアプローチです。MTとQuickが同じ速度で走っているときは、あなたのアプローチは正しかったのです。 今ではMTがQuickを100倍も追い越しています。 ちなみに、各種パッケージで動作するプログラムは、1回限りの計算に最適化されていますが、MTはストリーミング計算を使うことが多いんです。 例えばRは、N点の合計をNで割ったものをRとして計算する。MTでは最初の1点だけがこの方法でカウントされるのに対し、残りは2段階でカウントされ、新しい計算に含まれない最後の1点が差し引かれ、新しい計算が追加されるのです。 したがって、Rは開発のみに有用であり、多くの可能性があり、何を適用するかは誰にもわからない。そして、開発が終わり（そうでなくても実験が終わり）、TCのアルゴリズムが決まったら、すべてをMqlに移管すべきです。 ゲートウェイを少なくし、問題を少なくする。 СанСаныч Фоменко 2018.02.11 14:53 #6642 ニコライ・デムコ....とTCのアルゴリズムが決定しているので、すべてをMqlに変換する必要があります。 このようなことを書く人がいるということは、一つのことを意味しています。 Mykola Demko 2018.02.11 14:59 #6643 サンサニッチ・フォメンコこのようなことを書く人がいるということは、一つのことを意味している。それは、彼らがこの問題について微塵も考えていないということだ問題は、現代人は高級言語に慣れすぎていて、同じ確率密度関数を算術演算で 実装する方法すら理解していないことです。 Yuriy Asaulenko 2018.02.11 15:13 #6644 ニコライ・デムコ問題は、現代人は高級言語に慣れすぎていて、同じ確率密度関数を算術演算で 実装する方法すら理解できていないことです。まあ、仮にそうだとして。仮に私には理解できないかもしれない--そんなことはどうでもいい。 なぜ実装する必要があるのか理解できないのですが・・・？そして、原則的に理解する必要はありません。電気ケトルの構造や回路理論の知識は、それでお湯を沸かして使う分には全く必要ないのです。 Mykola Demko 2018.02.11 15:38 #6645 ユーリイ・アサウレンコまあ、わかったといえばわかったのですが。仮にそうだとしよう。理解できないかもしれない-そんなことはどうでもいい。 なぜ実装する必要があるのか理解できない......？そして、原則的に理解する必要はありません。電気ケトルの構造や回路理論の知識は、それでお湯を沸かして使う分には全く必要ないのです。いつも同じ場所でお湯を沸かすには、コンセントをテーブルまで差し込むか、延長コードを何十本もつないで冷蔵庫の裏や椅子の裏、風呂場を通って設置し、他の電化製品をたくさん差し込むなど、考え方がはっきりしていればいいのですが...。 選択肢1：mqlで書かれたEAをVPSで 動作させ、問題を忘れる。 オプション2：統合ハリネズミと恐ろしい作成、あなたの家のコンピュータに置く（一般的にハード男です）、3倍の価格のためのリモートVPNで大丈夫、そして毎日揺れ失敗したかどうか。 Yuriy Asaulenko 2018.02.11 15:51 #6646 ニコライ・デムコ 選択肢2：ハリネズミのインテグレーションを作り、それを自宅のパソコンに入れ（これは面倒）、3倍の値段のリモートVPNで大丈夫、毎日、失敗しないかどうか揺さぶりながら確認する。 それでいいんです。それもありますが、システムが動いていてコントロールが必要なときは、あまり離れられないんです。それが問題なんです。UPUにも問題はあるが、それほどでもない、ということで合意した。 でも、ハリネズミにはハリネズミの方がいいんです。MKUL1台でシステムをどうするか、どれくらいの時間と手間がかかるか、いいアイデアが浮かばないんです。外部マット機能はもちろん、DBからIPクライアントまで、多くの外部ソフトウェアがあります。それをMQLひとつで全部やるのは現実的じゃないし、まあ、UPUだとさらに無理なんですけどね。 SZY 同じC++/C#に挟むのは問題ないと言わざるを得ませんね。 Mykola Demko 2018.02.11 15:58 #6647 ユーリイ・アサウレンコそれでいいんです。また、システムが動いていてコントロールが必要なときは、あまり離れられないんです。それが問題なんです。UPUの場合も問題はありますが、少ないということで合意しています。 でも、ハリネズミにはハリネズミの方がいいんです。MKUL1台でシステムをどうするか、どれくらいの時間と手間がかかるか、いいアイデアが浮かばないんです。外部マット機能はもちろん、DBからIPクライアントまで、多くの外部ソフトウェアがあります。そして、それを1つのMCLですべて行うのは、単純に現実的ではありませんし、まあ、UPUでも無理な話です。でも、否定はしません、複雑なんです。 Maxim Dmitrievsky 2018.02.11 16:19 #6648 ニコライ・デムコオプション1：EAをmqlで書き、VPS上で 動作させ、問題を忘れる。これは、すべてをmqlだけで行うようにするための最大のポイントです。 Forester 2018.02.11 16:21 #6649 R上の構造と重みを求めよ（シグモイドで）。そして、それをAlglib上のNSにコピーします。同じ結果になることを祈って...。 alglibは学習が何十倍も遅くなるので、スピード重視で使うR。 Forester 2018.02.11 16:24 #6650 ところで、Rからネットワークの応答を計算するコードに、重みと構造のコンバータはないのですか？アルグリーべも必要ないように。 1...658659660661662663664665666667668669670671672...3399 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
まったくもって、正しいアプローチです。
今のところ、絶対に間違ったアプローチです。MTとQuickが同じ速度で走っているときは、あなたのアプローチは正しかったのです。
今ではMTがQuickを100倍も追い越しています。
ちなみに、各種パッケージで動作するプログラムは、1回限りの計算に最適化されていますが、MTはストリーミング計算を使うことが多いんです。
例えばRは、N点の合計をNで割ったものをRとして計算する。MTでは最初の1点だけがこの方法でカウントされるのに対し、残りは2段階でカウントされ、新しい計算に含まれない最後の1点が差し引かれ、新しい計算が追加されるのです。
したがって、Rは開発のみに有用であり、多くの可能性があり、何を適用するかは誰にもわからない。そして、開発が終わり（そうでなくても実験が終わり）、TCのアルゴリズムが決まったら、すべてをMqlに移管すべきです。
ゲートウェイを少なくし、問題を少なくする。
....とTCのアルゴリズムが決定しているので、すべてをMqlに変換する必要があります。
このようなことを書く人がいるということは、一つのことを意味しています。
このようなことを書く人がいるということは、一つのことを意味している。それは、彼らがこの問題について微塵も考えていないということだ
問題は、現代人は高級言語に慣れすぎていて、同じ確率密度関数を算術演算で 実装する方法すら理解していないことです。
問題は、現代人は高級言語に慣れすぎていて、同じ確率密度関数を算術演算で 実装する方法すら理解できていないことです。
まあ、仮にそうだとして。仮に私には理解できないかもしれない--そんなことはどうでもいい。
なぜ実装する必要があるのか理解できないのですが・・・？そして、原則的に理解する必要はありません。電気ケトルの構造や回路理論の知識は、それでお湯を沸かして使う分には全く必要ないのです。
まあ、わかったといえばわかったのですが。仮にそうだとしよう。理解できないかもしれない-そんなことはどうでもいい。
なぜ実装する必要があるのか理解できない......？そして、原則的に理解する必要はありません。電気ケトルの構造や回路理論の知識は、それでお湯を沸かして使う分には全く必要ないのです。
いつも同じ場所でお湯を沸かすには、コンセントをテーブルまで差し込むか、延長コードを何十本もつないで冷蔵庫の裏や椅子の裏、風呂場を通って設置し、他の電化製品をたくさん差し込むなど、考え方がはっきりしていればいいのですが...。
選択肢1：mqlで書かれたEAをVPSで 動作させ、問題を忘れる。
オプション2：統合ハリネズミと恐ろしい作成、あなたの家のコンピュータに置く（一般的にハード男です）、3倍の価格のためのリモートVPNで大丈夫、そして毎日揺れ失敗したかどうか。
選択肢2：ハリネズミのインテグレーションを作り、それを自宅のパソコンに入れ（これは面倒）、3倍の値段のリモートVPNで大丈夫、毎日、失敗しないかどうか揺さぶりながら確認する。
それでいいんです。それもありますが、システムが動いていてコントロールが必要なときは、あまり離れられないんです。それが問題なんです。UPUにも問題はあるが、それほどでもない、ということで合意した。
でも、ハリネズミにはハリネズミの方がいいんです。MKUL1台でシステムをどうするか、どれくらいの時間と手間がかかるか、いいアイデアが浮かばないんです。外部マット機能はもちろん、DBからIPクライアントまで、多くの外部ソフトウェアがあります。それをMQLひとつで全部やるのは現実的じゃないし、まあ、UPUだとさらに無理なんですけどね。
SZY 同じC++/C#に挟むのは問題ないと言わざるを得ませんね。
それでいいんです。また、システムが動いていてコントロールが必要なときは、あまり離れられないんです。それが問題なんです。UPUの場合も問題はありますが、少ないということで合意しています。
でも、ハリネズミにはハリネズミの方がいいんです。MKUL1台でシステムをどうするか、どれくらいの時間と手間がかかるか、いいアイデアが浮かばないんです。外部マット機能はもちろん、DBからIPクライアントまで、多くの外部ソフトウェアがあります。そして、それを1つのMCLですべて行うのは、単純に現実的ではありませんし、まあ、UPUでも無理な話です。
でも、否定はしません、複雑なんです。
オプション1：EAをmqlで書き、VPS上で 動作させ、問題を忘れる。
これは、すべてをmqlだけで行うようにするための最大のポイントです。
alglibは学習が何十倍も遅くなるので、スピード重視で使うR。