トレンド戦略に関連するIO（ディシジョンツリー／フォレスト）を開発するためのチームを結成する。 - ページ 18 1...11121314151617181920 新しいコメント Aleksey Vyazmikin 2018.07.09 19:44 #171 Aleksey Panfilov:だから、チームはキャンセルになる。) そして、管理されたグループが存在することになります。) すでに確立されたチームであっても管理することは、95％の確率で結果を殺すことになるのです。 そして、すでに存在しないものを管理するためには、非常に強力な切り札が必要です。)) そろそろ切り札を見せたいところです。 手法も重要です。 供給はあるが、需要の発現は一切ない。 もし、この段階で、潜在的なメンバーが積極的に行動しようとしないのであれば、私は彼らのモチベーションに自信が持てません。 とても残念なことです。 行政がなければ前に進めない--参加者自身が進行方向を決めるというスキームを提案していますが、最も快適な状態を想像するのは難しいですね。 Aleksey Vyazmikin 2018.07.09 19:46 #172 Roffild:その中で、GitLabに登録しているレプブも登録されていない...。 チームはすぐにでもApache 2.0ライセンスで構築されるべきで、見知らぬ人に協力的な倫理観を強制したかったのでしょう。 まあ、社長はソフトウエア開発のことは全然知らないんですけどね。登録は数分で完了、形式的なものです。 チームは、自分自身とチームメンバー全員の利益のために働くべきであり、気分を害するようなことはしてはならない。 アイデアを練ることと、それをコーディングすることは別物です。 Roffild 2018.07.09 20:48 #173 Aleksey Vyazmikin:登録は数分のことで、形式的なものに過ぎません。 チームは、自分自身とチームメンバー全員の利益のために働くべきであり、気が向いたときに鼻をほじくるようなことはしてはならないのです。 アイデアを練ることと、それをコーディングすることは別物です。分の仕事」なのに、なぜやらないのか？チームがないからワークスペースがない。ワークスペースがないからチームもない...。 そして、この分野では、少なくとも擬似的なコードで、アイデアを即座に実装することが必要です。 Aleksey Vyazmikin 2018.07.09 21:41 #174 Roffild:分ビジネス」なら、なぜやらないのか？チームがないからワークスペースがない。ワークスペースがないからチームもない...。そしてこの分野では、少なくとも疑似コードでアイデアをすぐに実装しなければならない。チームが存在するのは、人々が一緒に仕事をしたくないからではなく、みんな（そのほとんどが）他の人のアイデアを聞くことに興味があり、マキシムが提案したチャットルームという形式は、それにちょうどいいのです。 もしかしたら、今の段階で不信感や自分の考えを明らかに することを恐れているのは、利害関係のコミュニケーションの変種なのかもしれませんね。 何かをする前に、最終的にどうなるかを理解すること、つまり設計図が必要です。私は、仕事のプロセスの構成について、どうしたいか、どう見えるかという意見を述べ、その希望を念頭に置いてワークスペースを構成することを提案しました。 Aleksey Vyazmikin 2018.07.09 21:47 #175 市民 - すべては私たちの手の中にあります 市場は個人の心理的問題を解決する場ではなく、収入を得るためのフィールドなのです 自分一人では動かせない。 Ivan Negreshniy 2018.07.10 06:27 #176 Aleksey Vyazmikin:というわけで、ごちゃごちゃになってしまいましたが、フォーラムエンジンは多機能なのでしょうか？RESTについて読んだことがありますが、裸のアーキテクチャなので、フォーラムのソースコードを探した方がいいのでしょうか？ 他のスクリプトが再生できるって、どこで再生できるんだ？普通のユーザーに売ることを想像して、その製品が何を与えてくれるのか、何に合うのか、人間的な言葉で説明してくださいよ。必要で大切なことだと思いますが、その理由がわかりません、ありがとうございました。何を説明するかというと、上記ではMQLスクリプトからローカルコンピュータにインストールされているPythonにアクセスし、ニューラルネットワークモデルを学習し、ファイルに保存し、それをロードしてPredictメソッドを呼び出して作業する例を示しましたが、今回は、MQLスクリプトからPythonにアクセスし、ニューラル・ネットワークモデルを学習し、それをファイルに保存し、ロードしてPredictメソッドを呼び出して作業します。https://www.mql5.com/ru/forum/261479/page16#comment_8011085同じパターンを使って、pythonライブラリにある何百ものIOモデルを作成し、データで学習させることができます。同じサンプルを使って、EAやインジケータにクライアントパーツを作成し、初期化時にモデルファイルをロードし、あなた自身の現在のデータでPredictメソッドを呼び出すことでポーリングすることが可能です。NamedPipesとRESTプロトコルのサポートにより、指定されたスクリプト、Expert AdvisorsまたはIndicatorsは、ローカルコンピュータとネットワーク上のリモート両方で、MOモデルでDLLなしで動作します。 RESTスクリプトを使用する場合、NamedPipesとは異なり、MQLからのテキストはFileWriteStringではなく、WebRequestで公開URL（例えばエンジンが動作しているVPS）に送信する必要があります。 Собираю команду для развития МО (Дерева решения/леса) применительно к трендовым стратегиям 2018.07.07www.mql5.com Предлагаю сплотиться для решения задачи МО применительно к трендам, т.е... Aleksey Vyazmikin 2018.07.10 10:41 #177 Ivan Negreshniy:何を説明するかというと、上記ではMQLスクリプトからローカルコンピュータにインストールしたPythonを呼び出し、ニューラルネットワークモデルを学習し、ファイルに保存し、それをロードしてPredictメソッドを呼び出して作業する例を示しました。https://www.mql5.com/ru/forum/261479/page16#comment_8011085同じパターンを使って、Pythonのライブラリで何百もあるMOモデルを作り、それをデータで学習させることができます。同じパターンを使って、Expert AdvisorやIndicatorにクライアントパーツを作成し、初期化時にモデルファイルをロードし、自身の現在のデータでPredictメソッドを呼び出すことでポーリングすることができます。NamedPipesとRESTプロトコルのサポートにより、指定されたスクリプト、Expert AdvisorsまたはIndicatorsは、ローカルコンピュータとネットワーク上のリモート両方で、MOモデルでDLLなしで動作します。 RESTスクリプトを使用する場合、NamedPipesとは異なり、MQLからのテキストはFileWriteStringではなく、WebRequestで公開URL（例えばエンジンが動作しているVPS）に送信する必要があります。一般的には、計算されたモデルを活性化させるためのツールであることは明らかです。 でも、ストラテジーオプティマイザーの扱いがまだよくわからない...。 Aleksey Vyazmikin 2018.07.10 12:32 #178 木についての感想は、役に立つかもしれないので、残しておきます。 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム トレーディングにおける機械学習：理論と実践（Trading and Beyond） アレクセイ・ヴャズミキン さん 2018.07.10 14:18 昨日、ふと思ったのですが、なぜ私たちは決定木、つまり実体を記述したモデルを探すのでしょうか？つまり、なぜ実体全体を記述する必要があるのか、その実体の中で最も理解しやすく予測しやすい部分を探せばいいのではないか、ということです。私は、木の葉を集めるのだから、完全な決定木を作らずにその葉を見つける方法を使えば、同じ計算時間でも品質が向上するのではないかと考えたのです。 インターネットを検索しても、そのような方法はどこにも見当たりません。もしかしたら、そのような展開を知っている人がいるかもしれません。 アルゴリズムを考える上で、まず、予測変数（クラスの1つの予測能力を示す）を選択する必要があり、その際、予測変数はバイナリにする必要があります（そのためには、予測変数ごとに独自のサンプルを形成するか、一般的なサンプルから除外マージンを形成するか（どちらがより合理的でしょうか））。そして、選択した予測因子（とその組み合わせ）を使って特定のクラス（私の場合は3クラス）のスタブを構築し、そのスタブを使って残りの予測因子を構築します。同時に、特定のクラスを優先してチェックすることも可能です。そして、その考え方に従って、特定のターゲットクラスに対して最も分類しやすい領域を探し出していきます。そして、残された領域は、ただの無為・無期待のフィールドとなるのです。 もちろん、葉っぱが重なっているところを確認し、その場合は平均的な結果にすることも可能です。そして、そのようなツリーを作ることができるのですが、異なるターゲットの異なるエリアでの密度のため、投票要素を持つのです。 このアイデアはどうでしょうか？ Ivan Negreshniy 2018.07.12 12:05 #179 Aleksey Vyazmikin:木の感想は、役に立つかもしれないので、残しておきます。 しかし、残念ながら進歩はなく、実用的な成果もなく、基本的にすべて洪水と根拠のない宣言で終わっています。 おそらくこれは、トレーディングIOツールの表示方法、つまりデータの形式やモデル、結果の客観的評価などが統一されていないため、お互いに建設的なコミュニケーションをとり、実験結果を共有し、合理的な結論を出すことができないからでしょう。 ましてや、開発者という一個人のパフォーマーを客観的に評価する方法がないのでは意味がない......。） MoDのスレッドでこの問題を提起する試みがありましたが、今のところ相互の理解は得られていません。 このテーマのマニアであるあなたなら、何かできるかも？ Aleksey Vyazmikin 2018.07.12 12:30 #180 Ivan Negreshniy:多くの人がここで自分の考え - アイデアを述べ、ある人はメカニズム - アルゴリズムを提案し、時には実行 - レディメイドのプログラムにまで至りますが、残念ながら進歩もなく、実用的な結果もなく、基本的にすべてが洪水と根拠のない宣言で終わります。 おそらくこれは、トレーディングIOツールの表示方法、つまりデータの形式やモデル、結果の客観的評価などが統一されていないため、お互いに建設的なコミュニケーションをとり、実験結果を共有し、合理的な結論を出すことができないからでしょう。 ましてや、開発者という一個人のパフォーマーを客観的に評価する方法がないのでは、何の意味もないでしょう（笑)。 MoDのスレッドでこの問題を提起する試みがありましたが、今のところ相互の理解は得られていません。このテーマの愛好家であるあなたなら、何かできるかもしれませんね？標準的な評価が適切でないことは、以前にも書きましたが、私も同意見です。特に、トレンド戦略ということであれば、それは一目瞭然です。基本戦略で最適な評価基準を探し、それを他の戦略に移植するのがよいでしょう。私の見るところ、MOブランチは主にバーの開店時にどのように閉まるかを予測しようとしています。そして、そこでも推測・無推測の指標は適切かもしれませんが、そこでもトレンド戦略はもちろんのこと、ポイントも推計に加味する必要があります。 下の写真では、スクエア1のエントリーポイントは、利益が出るスクエア2よりもはるかに良い（より多くの利益をもたらす）でしょう、一方、スクエア3では、資産を売却したときに損失で閉じますが、資産を購入したときに最低価格が形成されるまで、それは利益をもたらすことはないでしょう。 つまり、エントリーの推測の割合が大きくても、この大きな値が1マス目よりも2マス目に集中していれば、誤差の小さな値が全体の利益を上書きしてしまうことがあることがわかると思います。 そこで、シグナルがどの領域に集中しているか、どの領域で利益が出るか、あるいは損失が出るかをモデル評価で考慮し、決定木を構成する際に考慮したいと思うようになりました。 1...11121314151617181920 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
だから、チームはキャンセルになる。)
そして、管理されたグループが存在することになります。)
すでに確立されたチームであっても管理することは、95％の確率で結果を殺すことになるのです。
そして、すでに存在しないものを管理するためには、非常に強力な切り札が必要です。))
そろそろ切り札を見せたいところです。
供給はあるが、需要の発現は一切ない。
もし、この段階で、潜在的なメンバーが積極的に行動しようとしないのであれば、私は彼らのモチベーションに自信が持てません。
とても残念なことです。
行政がなければ前に進めない--参加者自身が進行方向を決めるというスキームを提案していますが、最も快適な状態を想像するのは難しいですね。
その中で、GitLabに登録しているレプブも登録されていない...。
チームはすぐにでもApache 2.0ライセンスで構築されるべきで、見知らぬ人に協力的な倫理観を強制したかったのでしょう。
まあ、社長はソフトウエア開発のことは全然知らないんですけどね。
登録は数分で完了、形式的なものです。
チームは、自分自身とチームメンバー全員の利益のために働くべきであり、気分を害するようなことはしてはならない。
アイデアを練ることと、それをコーディングすることは別物です。
登録は数分のことで、形式的なものに過ぎません。
チームは、自分自身とチームメンバー全員の利益のために働くべきであり、気が向いたときに鼻をほじくるようなことはしてはならないのです。
アイデアを練ることと、それをコーディングすることは別物です。
分の仕事」なのに、なぜやらないのか？チームがないからワークスペースがない。ワークスペースがないからチームもない...。
そして、この分野では、少なくとも擬似的なコードで、アイデアを即座に実装することが必要です。
分ビジネス」なら、なぜやらないのか？チームがないからワークスペースがない。ワークスペースがないからチームもない...。
そしてこの分野では、少なくとも疑似コードでアイデアをすぐに実装しなければならない。
チームが存在するのは、人々が一緒に仕事をしたくないからではなく、みんな（そのほとんどが）他の人のアイデアを聞くことに興味があり、マキシムが提案したチャットルームという形式は、それにちょうどいいのです。
もしかしたら、今の段階で不信感や自分の考えを明らかに することを恐れているのは、利害関係のコミュニケーションの変種なのかもしれませんね。
何かをする前に、最終的にどうなるかを理解すること、つまり設計図が必要です。私は、仕事のプロセスの構成について、どうしたいか、どう見えるかという意見を述べ、その希望を念頭に置いてワークスペースを構成することを提案しました。
市民 - すべては私たちの手の中にあります
市場は個人の心理的問題を解決する場ではなく、収入を得るためのフィールドなのです
自分一人では動かせない。
というわけで、ごちゃごちゃになってしまいましたが、フォーラムエンジンは多機能なのでしょうか？RESTについて読んだことがありますが、裸のアーキテクチャなので、フォーラムのソースコードを探した方がいいのでしょうか？
他のスクリプトが再生できるって、どこで再生できるんだ？普通のユーザーに売ることを想像して、その製品が何を与えてくれるのか、何に合うのか、人間的な言葉で説明してくださいよ。必要で大切なことだと思いますが、その理由がわかりません、ありがとうございました。
何を説明するかというと、上記ではMQLスクリプトからローカルコンピュータにインストールされているPythonにアクセスし、ニューラルネットワークモデルを学習し、ファイルに保存し、それをロードしてPredictメソッドを呼び出して作業する例を示しましたが、今回は、MQLスクリプトからPythonにアクセスし、ニューラル・ネットワークモデルを学習し、それをファイルに保存し、ロードしてPredictメソッドを呼び出して作業します。
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
同じパターンを使って、pythonライブラリにある何百ものIOモデルを作成し、データで学習させることができます。同じサンプルを使って、EAやインジケータにクライアントパーツを作成し、初期化時にモデルファイルをロードし、あなた自身の現在のデータでPredictメソッドを呼び出すことでポーリングすることが可能です。
NamedPipesとRESTプロトコルのサポートにより、指定されたスクリプト、Expert AdvisorsまたはIndicatorsは、ローカルコンピュータとネットワーク上のリモート両方で、MOモデルでDLLなしで動作します。
RESTスクリプトを使用する場合、NamedPipesとは異なり、MQLからのテキストはFileWriteStringではなく、WebRequestで公開URL（例えばエンジンが動作しているVPS）に送信する必要があります。
何を説明するかというと、上記ではMQLスクリプトからローカルコンピュータにインストールしたPythonを呼び出し、ニューラルネットワークモデルを学習し、ファイルに保存し、それをロードしてPredictメソッドを呼び出して作業する例を示しました。
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
同じパターンを使って、Pythonのライブラリで何百もあるMOモデルを作り、それをデータで学習させることができます。同じパターンを使って、Expert AdvisorやIndicatorにクライアントパーツを作成し、初期化時にモデルファイルをロードし、自身の現在のデータでPredictメソッドを呼び出すことでポーリングすることができます。
NamedPipesとRESTプロトコルのサポートにより、指定されたスクリプト、Expert AdvisorsまたはIndicatorsは、ローカルコンピュータとネットワーク上のリモート両方で、MOモデルでDLLなしで動作します。
RESTスクリプトを使用する場合、NamedPipesとは異なり、MQLからのテキストはFileWriteStringではなく、WebRequestで公開URL（例えばエンジンが動作しているVPS）に送信する必要があります。
一般的には、計算されたモデルを活性化させるためのツールであることは明らかです。
でも、ストラテジーオプティマイザーの扱いがまだよくわからない...。
木についての感想は、役に立つかもしれないので、残しておきます。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
トレーディングにおける機械学習：理論と実践（Trading and Beyond）
アレクセイ・ヴャズミキン さん 2018.07.10 14:18
昨日、ふと思ったのですが、なぜ私たちは決定木、つまり実体を記述したモデルを探すのでしょうか？つまり、なぜ実体全体を記述する必要があるのか、その実体の中で最も理解しやすく予測しやすい部分を探せばいいのではないか、ということです。私は、木の葉を集めるのだから、完全な決定木を作らずにその葉を見つける方法を使えば、同じ計算時間でも品質が向上するのではないかと考えたのです。
インターネットを検索しても、そのような方法はどこにも見当たりません。もしかしたら、そのような展開を知っている人がいるかもしれません。
アルゴリズムを考える上で、まず、予測変数（クラスの1つの予測能力を示す）を選択する必要があり、その際、予測変数はバイナリにする必要があります（そのためには、予測変数ごとに独自のサンプルを形成するか、一般的なサンプルから除外マージンを形成するか（どちらがより合理的でしょうか））。そして、選択した予測因子（とその組み合わせ）を使って特定のクラス（私の場合は3クラス）のスタブを構築し、そのスタブを使って残りの予測因子を構築します。同時に、特定のクラスを優先してチェックすることも可能です。そして、その考え方に従って、特定のターゲットクラスに対して最も分類しやすい領域を探し出していきます。そして、残された領域は、ただの無為・無期待のフィールドとなるのです。
もちろん、葉っぱが重なっているところを確認し、その場合は平均的な結果にすることも可能です。そして、そのようなツリーを作ることができるのですが、異なるターゲットの異なるエリアでの密度のため、投票要素を持つのです。
このアイデアはどうでしょうか？
木の感想は、役に立つかもしれないので、残しておきます。
しかし、残念ながら進歩はなく、実用的な成果もなく、基本的にすべて洪水と根拠のない宣言で終わっています。
おそらくこれは、トレーディングIOツールの表示方法、つまりデータの形式やモデル、結果の客観的評価などが統一されていないため、お互いに建設的なコミュニケーションをとり、実験結果を共有し、合理的な結論を出すことができないからでしょう。
ましてや、開発者という一個人のパフォーマーを客観的に評価する方法がないのでは意味がない......。）
MoDのスレッドでこの問題を提起する試みがありましたが、今のところ相互の理解は得られていません。 このテーマのマニアであるあなたなら、何かできるかも？
多くの人がここで自分の考え - アイデアを述べ、ある人はメカニズム - アルゴリズムを提案し、時には実行 - レディメイドのプログラムにまで至りますが、残念ながら進歩もなく、実用的な結果もなく、基本的にすべてが洪水と根拠のない宣言で終わります。
おそらくこれは、トレーディングIOツールの表示方法、つまりデータの形式やモデル、結果の客観的評価などが統一されていないため、お互いに建設的なコミュニケーションをとり、実験結果を共有し、合理的な結論を出すことができないからでしょう。
ましてや、開発者という一個人のパフォーマーを客観的に評価する方法がないのでは、何の意味もないでしょう（笑)。
MoDのスレッドでこの問題を提起する試みがありましたが、今のところ相互の理解は得られていません。このテーマの愛好家であるあなたなら、何かできるかもしれませんね？
標準的な評価が適切でないことは、以前にも書きましたが、私も同意見です。特に、トレンド戦略ということであれば、それは一目瞭然です。基本戦略で最適な評価基準を探し、それを他の戦略に移植するのがよいでしょう。私の見るところ、MOブランチは主にバーの開店時にどのように閉まるかを予測しようとしています。そして、そこでも推測・無推測の指標は適切かもしれませんが、そこでもトレンド戦略はもちろんのこと、ポイントも推計に加味する必要があります。
下の写真では、スクエア1のエントリーポイントは、利益が出るスクエア2よりもはるかに良い（より多くの利益をもたらす）でしょう、一方、スクエア3では、資産を売却したときに損失で閉じますが、資産を購入したときに最低価格が形成されるまで、それは利益をもたらすことはないでしょう。
つまり、エントリーの推測の割合が大きくても、この大きな値が1マス目よりも2マス目に集中していれば、誤差の小さな値が全体の利益を上書きしてしまうことがあることがわかると思います。
そこで、シグナルがどの領域に集中しているか、どの領域で利益が出るか、あるいは損失が出るかをモデル評価で考慮し、決定木を構成する際に考慮したいと思うようになりました。