"New Neural "は、MetaTrader 5プラットフォーム用のオープンソース・ニューラルネットワークエンジンプロジェクトです。 - ページ 68

 

"reverse "は適応的な引数によってフィットネス関数の偏導関数を求めるために必要なもので、したがって、どんな勾配法(例えば、あらゆる修正におけるBackProp)も "reverse "を必要とします。

他の方式では必要ない

 

少し補足させてください。

エンドユーザーとして、私はブラックボックスから次のことを必要としています。

最後の20-1000本のバー、数個のシンボルを入れました。

それに対してブラックボックスはこう言います。最後の15小節で安定したクラスタ状態(フラット)が観察される。

これらのクラスタは、1995年1月1日から95年1月20日までの歴史的期間にあります。

クラスターの寿命は、最小で20本、最大で74本、平均で47本で、歴史上125回観測されています。

推奨される戦略は、チャンネルの境界線から取引することです。チャンネルのレベルは1.2567-1.2687です。

あるいは

最後の65小節で安定したクラスタ状態(フラット)が観察される。

これらのクラスタは、1995年1月1日から95年1月20日などの履歴期間であるため、グラフを強調することができます。

クラスタの最小寿命20バー、最大74バー、平均47バー、全体の歴史は125回観測されました。

推奨戦略はチャネルを突破することで、チャネルレベルは1.2567-1.2687です。

今、頭を悩ませているところです。NSでも可能です。

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
yu-sha さん。

"reverse "は適応的な引数によってフィットネス関数の偏導関数を求めるために必要なもので、したがって、どんな勾配法(例えば、あらゆる修正におけるBackProp)も "reverse "を必要とします。

他の方式では必要ありません。

ウェイト調整のためのフォワードムーブというのはないと考えていいのでしょうか?

であり、学習で前進を用いるアルゴリズムでは、実際には複数の(並列に存在する)重み配列を用いている。

その中から最適なものを選ぶことで

それとも、直接ストロークでウェイトを調整するようなアルゴリズムがまだあるのでしょうか?

 
ウラン です。

目盛りの素直なストローク調整というのはないと考えていいのでしょうか?

前方移動を用いるアルゴリズムでは、実際には複数の(並列に存在する)重み付けアレイを学習で使用する。

その中から最適なものを選ぶことで

はい、その通りです。

あえてもっと難しく言うと、天秤の調整も後ろからストロークするようなことはありません。

"逆ストローク "とは、複雑な関数の微分を求める過程を私たちが視覚的に認識することであり、その本質はニューラルネットワークである

学習はネットワーク自体の外部にあるプロセスである

学習方法の違いにより、ネットワークのトポロジーや推定される関数の形式に対する要求も異なる

勾配法は最も厳しい、確率法は雑食性

 

声を大にして思うこと・・・。

この形式のプロジェクトは、ほぼ絶望的だと私は考えています。

まず、みんながそれぞれの方向に引っ張っていくからです。プロジェクトにすべてを任せてしまいたい人、プロジェクトにトポロジーそのものを組み立ててほしい人、すべてを第3の空間を目標に飛んでほしい人。

2つ目は、操作に対する誤解からです。

3つ目は、おそらく最も重要なことですが、これまでのプロジェクトの目標が明確でなかったからです。

___________________________

とにかく、考え出したのは、「本当に必要なのか?エコーネットワークは、別プロジェクトとして割り切って推進したほうがいいですね。

世界征服の計画ではなく、機能的で効果的。

では、頑張ってください。このプロジェクトが永久になくならないことを願っています。

___________________________

何か間違っていたらごめんなさい。

 
TheXpert です。

思いを声に出して...。

MetaQuotesのガイディングハンドが絶対必要
 
TheXpert:

声を大にして思うこと・・・。

この形式のプロジェクトは、ほぼ絶望的だと私は考えています。

まず、みんながそれぞれの方向に引っ張っていくからです。プロジェクトにすべてを任せてしまいたい人、プロジェクトにトポロジーそのものを組み立ててほしい人、すべてを第3の空間を目標に飛んでほしい人。

2つ目は、操作に対する誤解からです。

3つ目は、おそらく最も重要なことですが、これまでのプロジェクトの目標が明確でなかったからです。

___________________________

とにかく、考え出したのは、「本当に必要なのか?エコーネットワークは、別プロジェクトとして割り切って推進したほうがいいですね。

世界征服の計画ではなく、機能的で効果的。

では、頑張ってください。このプロジェクトが永久になくならないことを願っています。

___________________________

何か間違っていたらごめんなさい。

一般的に、オープンソースプロジェクトは どのように実装されているのでしょうか?

通常、すべてはエンジンを書き、プロジェクトの基本的なイデオロギーを開発する一人のエバンジェリスト(想定外のトーバルズ)から生まれます。そして、プロジェクトが拡大するにつれて、最終的な結果に関心を持つ新しい勢力が加わってくる。そしてここで、ゼロからのスタートであることが判明し、方向性が見えない、方向性がないからです。最良の選択肢は、一人で開発を試みるか、地理的に離れていない非常に緊密なチームで開発することです。そして、そのエンジンが面白くなれば、人々は手に取ってくれるでしょう。この状況で生き残れるのは、この選択肢しかないと思います。

 
TheXpert:

声を大にして思うこと・・・。


アンドレイ 1つの支店で3つのプロジェクトを 行うことは、誰も止めないよ。

実際にはすべてのブランチが同じものを扱っているので、1つのブランチ内で解決策を公開し、共有することができれば便利でしょう。

これで、コード生成、異なる実装のプラグイン化、ユニバーサルエンジンの3つの方向性が揃いました。

異なる実装を接続する(それがやりたいこと)ことは、コードジェネレータとユニバーサルエンジンの両方にとって非常に有効です。

ユニバーサルエンジンは、コードジェネレーターに有効です。そして、(MQLマスターのような)コードジェネレーターは、エンドユーザーにとっての簡便さとスピード(これらはすべて並列ブランチの最高の資質です)を兼ね備えていますが、どちらの方向にも使えません。

混乱を避けるために、GC RR UDという略語を使い、各投稿の略語をタイトルに入れたり、例えばカテゴリーごとに投稿を区別してGC RR UD カラーを使用することもできます。

 

吐いてほしいけど、無視されるだけだし。イエスかノーか、アドバイスを求められたのですね。

もし(YES)なら、賢い本を読みに行く。

を買ってきて、正しい方向へ蹴ってくれる。

 
Vladix:私の考えでは、この状況で生き残れる唯一の選択肢だと思います。
ありがとうございます :) 最終ポカ

ウラン です。

これで、コード生成、異なる実装の接続、ユニバーサルエンジンの3方向が揃いました。

むしろ、1つの実装を扱って、完璧に改善することを目指したいですね。

規模(ターゲット機能が明確でないタスクのクラス)ではジェネティックスに勝てないかもしれませんが、使用効率や学習効率では...。