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

 
TheXpert:

大規模プロジェクトでチームワークを発揮した経験のある人は?

また、VCSの経験という意味もあります。

一般に、私が理解する限り、一種のデッドロックがあります - ここでは、主に、すべての独立した鳥、自分自身で任意の問題を解決することができる(言語の独学から複雑な取引ロジックの記述に至るまで)。白鳥もザリガニもカワカマスも、その強力な資質を1台の荷車に乗せることはもちろん可能ですが、このフォーラムのこの支部で50ページにわたって活発に議論するには、十分な数です...。

さて、ポイントは、プロジェクトには、次のようなリーダーが必要だということです。

  • まず、プロジェクトの最終的な目標に興味を持つでしょう。
  • 第二に、プロジェクトをステージ、タスク、サブタスクに分け、このスレッドにいるプログラマーなら誰でも書き下ろし、妥当な時間で実行できるようにすることです。タスクとサブタスクはコンテキストに依存しない、つまり他のコードから可能な限り抽象化されたものであることが望ましい。
  • 第三に、プロジェクトを常に把握し、どの部分がどの程度まで出来上がっているか、サブタスクの解決をタスク全体に統合することが可能かどうかを知る必要がある。
理想的な解決策は、おそらくMetaQuotesの誰かで、同様の経験を持ち、さらにMQL-コミュニティとの関連でTeamWoxを試す機会となるでしょう。

 

数週間後にMCの活躍がなければ、このプロジェクトは 廃止されるか、他の場所の商業施設に移動することができます。

MCのコントロールがなければ、オプソースとしてのプロジェクトは意味がないのです。

 
Vladix:

一般に、私が理解する限り、一種のデッドロックがあります - ここでは、主に、すべての独立した鳥、自分自身で任意の問題を解決することができる(言語の自己学習から貿易の複雑なロジックを記述するために)。白鳥もザリガニもカワカマスも、その強力な資質を1台の荷車に乗せることはもちろん可能ですが、このフォーラムのこの支部で50ページにわたって活発に議論するには、十分な数です...。

さて、ポイントは、プロジェクトには、次のようなリーダーが必要だということです。

  • まず、プロジェクトの最終的な目標に興味を持つでしょう。
  • 第二に、プロジェクトをステージ、タスク、サブタスクに分け、このスレッドにいるプログラマーなら誰でも書き下ろし、妥当な時間で実行できるようにすることです。タスクとサブタスクはコンテキストに依存しない、つまり他のコードから可能な限り抽象化されたものであることが望ましい。
  • 第三に、プロジェクトを常に把握し、どの部分がどの程度まで出来上がっているか、解決したサブタスクをタスクの完全なソリューションに統合することが可能かどうかを知る必要がある。
理想的な解決策は、おそらく同じような経験を持つMetaQuotesの誰かで、さらにMQL-コミュニティとの関連でTeamWoxを試す機会にもなるでしょう。

すべてにおいて、彼の言ったことは真実である。このプロジェクトは、私たち一人ひとりが自分自身の力で行うことができるものです。

しかし、いつものように、悪魔は細部に宿るのです。

50ページの資料で、アイデアがあり、そこからかなり賢明な攻撃計画を立てることができると要約することができます。

個人でやっている人が多いが、チームワークに抵抗のある人はいない。結局、チームワークによってタスクを並列化 することができ、プロジェクト全体のスピードアップにつながるのです。

そして、ここからが本題です。古典的な意味でのチームワークは、実行者がタスクを受け取り、決められた時間内にそれを完了することを前提としています。そうすれば、プロジェクトの進捗を計画し、ワンセンターでパフォーマーにタスクを配分することが可能になります。実際、パフォーマーは自分のことで精一杯で、アウトソーシングされたプロジェクトにすべての時間を集中させることはできません。それゆえ、プロジェクトの展開にアンバランスが生じるのは必然です。

その解決策として、マネージャーがタスクを設定し、パフォーマーができることを行い、進捗状況や完了時期を報告する告知ボードが考えられると思います。TORが明確であれば、プロジェクトが始まる前に完成しているはずです :)

そしてもう一つ細かいことですが、変数やメソッドのよく使う名前のリストがあるといいですね、原則的なことではありませんが、標準化されていると楽でしょう。もちろん、そのようなリストを作るのは難しいが、名前を作る上での一般的な原則は、ある程度工夫することができる(あるいは、借りることができる)。

 
TheXpert です。

数週間後にMCの活躍がなければ、このプロジェクトは廃止されるか、他の場所の商業施設に移動することができます。

MKのコントロールがなければ、Opsourceとしてのプロジェクトは意味をなさなくなるからだ。

ということなんですね。

少なくとも、あなたと私の2人で、すべてを自分たちで行うことができます。

ZZYと、正しくおっしゃるとおり、カスタム開発はすでに商業的な展開になっています。

時間はかかるし、ソースコードを持っているのは1人だけなので、結論は簡単です。

 

さて、ファーザー・クリスマスを探している間。

脳内で掘り起こしたゴミを全部投稿します、もしかしたらここからTORくらいは作曲できるかもしれません。


グリッドエンジン
1. グリッド初期化
2. グリッドワークフロー
3.グリッドトレーニング

1) グリッドのトポロジーはバイナリフィールドで設定可能
詳細はこちら http://cgm.computergraphics.ru/content/view/25 section 7.Direct coding

文法への分離や直接コーディングは、すでに初期化法より上位の構造で、とにかく最終的にはすべて直接コーディングに帰着します。
そのため、トポロジーそのもの(ネットワークを指定する際の難関の大半を占める)は、直接符号化テーブルを作るためのメソッドを書くことに還元されるのです。
記事によると、逆リンクを指定することは不可能ですが、遅延の各ランクの演算子がリンクの独自の行列を作成する場合、問題はなくなります(ただし、行列はゼロ遅延の場合のように三角形ではなく、完全な行列になります)。
直接符号化方式を超える上部構造は、ネットワークがどのような遅延ランクを使用しているかを知っておく必要があることがわかりました。
ニューロンタイプも上部構造で指定する必要があります(この点については、ニューロンタイプを記述してオーバーロードする必要があるのか、もっと自由な方法で設定する必要があるのか、まだよく分かっていません)
今はハードタイプのオーバーロードにとどめておいて、ソフトコーディングの方法があれば、オーバーロードの一つとして追加すればよいでしょう。

2) ワーキングストロークは、所定のリンク(データ集計を利用)とニューロンタイプを条件に、5ページ目にレイアウトしました。 外部のデータは4つのアレイがあるはずです。グリッド入力ニューロン出力ウェイトグリッド出力グリッド入力とグリッド出力 への外部アクセスは、例えば給電やグリッドの運用に必要である。学習には、ウェイトへの
外部アクセスが必要です。計算のためにGPUに送信するためには、Neuron Outputsへの外部アクセスが 必要である。原則的に、データアレイは最初は外部であるべきで、すでにこれらの外部データはネットワークに集約されるべきだと思います。

3) トレーニング私は、ネットワークトポロジーに依存しない手法としてGAでトレーニングすることに傾倒しており、それをベースにして、可能であれば/必要であれば、適切なものにオーバーロードすることを提案しています。

その課題とは、3つのことです。

レイヤーは、同じイテレーションに依存せず、同じ型を持つニューロンの組合わせである。


 

断捨離は、実はとても現実的なことなんです。

例えば、IEvolvableというインタフェースがあります。グリッドのジェネティクス側のインターフェイス。ですから、例えば、あなたとアンドレイは、このインターフェースだけを使って、静かに遺伝子を見ることができるのです。

 

ところで、ここで多重継承が本当に便利なんです。

________________

同感です、今日中にインターフェイスを書き込んでみます。

ちなみに。プロジェクト マネージャーはgpwrでよい。その責任の一端を担うことになる。

原則として、プロジェクトを開始することができます。

 
うっ下火になりつつある。
 

このように、データバインディングの種類を自分自身や他の人に気づかせることができるのです。

//+------------------------------------------------------------------+
//| Пример Ассоциации, Агрегации, Композиции                         |
//+------------------------------------------------------------------+
/*///
   * Ассоциация обозначает связь между объектами. Агрегация и композиция это частные случаи ассоциации.
   * Агрегация предполагает, что объекты связаны взаимоотношением "part-of" (часть-целое). 
     Агрегация может быть множественной, 
     то есть один и тот же объект одновременно может быть агрегирован в несколько классов, либо объектов.
   * Композиция более строгий вариант агрегации. Дополнительно к требованию part-of накладывается условие, 
     что "часть" не может одновременно принадлежать разным "хозяевам", и заканчивает свое существование вместе с владельцем.
/*///
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
class Base
  {
public:
                     Base(void){};
                    ~Base(void){};
   int               a;
  };
//+------------------------------------------------------------------+

class A_Association
  {
public:
                     A_Association(void){};
                    ~A_Association(void){};
   void              Association(Base *a_){};
   // При ассоциации данные связываемого объекта 
   // будут доступны через указатель объекта только в методе, 
   // в который передан указатель.
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
class A_Aggregation
  {
   Base             *a;
public:
                     A_Aggregation(void){};
                    ~A_Aggregation(void){};
   void              Aggregation(Base *a_){a=a_;};
   // При агрегации данные связываемого объекта 
   // будут доступны через указатель объекта в любом методе класса.
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
class A_Composition
  {
   Base             *a;
public:
                     A_Composition(void){ a=new Base();};
                    ~A_Composition(void){delete a;};
   // При композиции объект становится частью класса.
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnStart()
  {
   Base a; 
   A_Association b;
   b.Association(GetPointer(a));
  }
 

ワークフローの問題にはニュアンスがあり、データ処理方法はニューロンタイプに依存するため、ニューロンタイプのオブジェクトの一部でなければなりません。

何をもってレイヤーとするかというニュアンスです。このような定式化をすると、GPUでの計算を整理するのが難しくなります。

TheXpertの 処方にこだわると、GPUへの負荷が問題になります。

全体としては、GPUの負荷の問題は引き継ぎますが、問題が少ない、妥協(組み合わせ)処方に傾いています。

層は、同じ反復に依存せず、同じ型を持つニューロンの組合わせである。

何か感想はありますか?

PS異論はありませんか?