"New Neural"은 MetaTrader 5 플랫폼용 신경망 엔진의 오픈 소스 프로젝트입니다. - 페이지 49

 
더엑스퍼트 :

누가 대규모 프로젝트에서 팀으로 일한 경험이 있습니까?

VCS에 대한 경험도 암시됩니다.

일반적으로 내가 이해할 수 있는 한 막다른 골목이 있었습니다. 기본적으로 모든 독립적인 새는 혼자서 모든 문제를 해결할 수 있습니다(독립적인 언어 연구에서 시작하여 복잡한 논리에 대한 설명으로 끝남). 무역). 물론 백조, 암 및 파이크를 모두 하나의 카트에 담을 수 있지만 이 포럼 스레드에서 50페이지의 활발한 토론에만 충분합니다.

이제 요점은 프로젝트 에 다음과 같은 리더가 있어야 한다는 것입니다.

  • 첫째, 프로젝트의 궁극적인 목표에 관심을 가질 것입니다.
  • 둘째, 프로젝트를 단계, 작업 및 하위 작업으로 나눌 수 있습니다. 이 분기의 모든 프로그래머는 합리적인 시간에 작성하고 수행할 수 있습니다. 동시에 작업과 하위 작업을 컨텍스트 독립적으로 만드는 것이 바람직합니다. 다른 코드에서 가능한 한 많이 추상화합니다.
  • 셋째, 그는 프로젝트의 최신 정보를 유지하고 어떤 부분이 준비되어 있고 얼마인지 알아야 합니다. 해결된 하위 작업을 전체 문제의 솔루션에 통합할 수 있는지 여부.
이상적인 옵션은 아마도 비슷한 경험을 가진 MetaQuotes의 사람일 것입니다. + MQL 커뮤니티와 관련하여 TeamWox 시스템을 시도해야 하는 이유가 있을 것입니다. 특히 Renat이 이미 이에 대해 이야기했기 때문입니다.

 

MK가 다음 몇 주 동안 활동을 표시하지 않으면 프로젝트 가 축소되거나 상업 채널 및 다른 곳으로 이전될 수 있습니다.

MK의 통제가 없으면 오픈 소스로서의 프로젝트는 의미를 잃습니다.

 
블라딕스 :

일반적으로 내가 이해할 수 있는 한 막다른 골목이 있었습니다. 기본적으로 모든 독립적인 새는 혼자서 모든 문제를 해결할 수 있습니다(독립적인 언어 연구에서 시작하여 복잡한 논리에 대한 설명으로 끝남). 무역). 물론 백조, 암 및 파이크를 모두 하나의 카트에 담을 수 있지만 이 포럼 스레드에서 50페이지의 활발한 토론에만 충분합니다.

이제 요점은 프로젝트에 다음과 같은 리더가 있어야 한다는 것입니다.

  • 첫째, 프로젝트의 궁극적인 목표에 관심을 가질 것입니다.
  • 둘째, 프로젝트를 단계, 작업 및 하위 작업으로 나눌 수 있습니다. 이 분기의 모든 프로그래머는 합리적인 시간에 작성하고 수행할 수 있습니다. 동시에 작업과 하위 작업을 컨텍스트 독립적으로 만드는 것이 바람직합니다. 다른 코드에서 가능한 한 많이 추상화합니다.
  • 셋째, 그는 프로젝트의 최신 정보를 유지하고 어떤 부분이 준비되어 있고 얼마인지 알아야 합니다. 해결된 하위 작업을 전체 문제의 솔루션에 통합할 수 있는지 여부.
이상적인 옵션은 아마도 비슷한 경험을 가진 MetaQuotes의 사람일 것입니다. + MQL 커뮤니티와 관련하여 TeamWox 시스템을 시도해야 하는 이유가 있을 것입니다. 특히 Renat이 이미 이에 대해 이야기했기 때문입니다.

일반적으로 모든 것이 옳았습니다. 우리 각자는 이 프로젝트를 스스로 수행할 수 있습니다.

그러나 평소와 같이 악마는 세부 사항에 있습니다.

공격의 50 페이지를 기반으로 아이디어가 있다고 요약 할 수 있으며 그로부터 완전히 정상적인 공격 계획을 세울 수 있습니다.

대부분이 개인이지만 팀 작업을 거부하는 사람은 아무도 없습니다. 마찬가지로 팀워크를 통해 작업을 병렬화할 수 있으므로 전체 프로젝트의 속도를 높일 수 있습니다.

그리고 여기에서 세부 사항이 시작됩니다. 고전적인 의미의 팀워크는 수행자가 작업을 받고 제 시간에 완료한다는 것을 의미합니다. 그러면 단일 센터에서 프로젝트의 홍보를 계획하고 수행자에게 작업을 분배할 수 있습니다. 사실 출연자들은 각자의 일로 바쁘고 오픈소스 프로젝트에 온종일 집중할 수 없다. 이것은 필연적으로 프로젝트 개발의 불균형으로 이어질 것입니다.

그 출구는 리더가 과업을 설정하고 출연자들이 할 수 있는 한 최선을 다해 진행 상황과 마감일을 보고하는 게시판일 수 있다고 생각합니다. TOR가 명확하게 공식화되면 프로젝트가 시작되기 전에 완료됩니다 :)

그리고 한 가지 더 자세히 말씀드리면, 일반적으로 통용되는 변수와 메소드의 이름 목록을 갖고 싶습니다. 필수 사항은 아니지만 표준화하면 더 쉬울 것입니다. 물론 그러한 목록을 작성하는 것은 어렵지만 이름 생성을 위한 몇 가지 일반적인 원칙을 개발(또는 차용)하는 것은 가능합니다.

 
더엑스퍼트 :

MK가 다음 몇 주 동안 활동을 표시하지 않으면 프로젝트가 축소되거나 상업 채널 및 다른 곳으로 이전될 수 있습니다.

MK의 통제가 없으면 오픈 소스로서의 프로젝트는 의미를 잃습니다.

당신은 진실을 말합니다.

우리 중 적어도 두 명을 위협하십시오. 당신과 나는 우리 스스로 모든 것을 할 수 있습니다.

ZZY님 말씀대로 개인 개발은 이미 상업적 개발입니다.

시간을 보내고 소스 코드가 하나만 있으면 결론은 간단합니다.

 

알겠습니다. 산타클로스 검색이 켜져 있는 동안

나는 내 두뇌에서 주운 모든 쓰레기를 배치 할 것입니다. 아마도 이것에서 적어도 일종의 TK를 만드는 것이 가능할 것입니다.


그리드 엔진
1. 그리드 초기화
2. 그리드 작업 스트로크
3. 메쉬 트레이닝

1) 메쉬 토폴로지는 이진 필드로 지정할 수 있습니다.
자세한 내용은 여기 http://cgm.computergraphics.ru/content/view/25 섹션 7. 직접 인코딩

문법이나 직접 코딩으로 나누는 것은 이미 초기화 방법에 대한 추가 기능이지만 결국에는 모두 직접 코딩으로 귀결됩니다.
따라서 토폴로지 자체(네트워크 설정의 어려움 중 가장 큰 부분)는 직접 코딩 테이블을 컴파일하기 위한 작성 방법으로 축소됩니다.
기사에 따르면 피드백을 설정할 수는 없지만 지연 연산자의 각 등급에 대해 고유한 연결 행렬을 만들면 문제가 사라집니다(행렬은 완전하고 지연이 0인 경우와 같이 삼각형이 아님).
직접 인코딩 방법을 통한 추가 기능은 네트워크에서 사용하는 지연 순위를 알아야 합니다.
뉴런 유형도 추가 기능에서 설정해야 합니다(이 점은 아직 해결되지 않았습니다. 뉴런 유형을 하드 코딩하고 오버로드해야 하는지 아니면 좀 더 자유로운 방법) ???
지금은 하드 타입의 오버로딩을 멈추고 소프트 코딩 방법이 있다면 오버로드된 타입 중 하나로 추가할 수 있습니다.

2) 작업 이동은 규정된 연결(데이터 집계 사용)과 뉴런 유형에 따라 결정됩니다. 이를 5페이지에 설명했습니다. 동시에 4개의 데이터 배열을 가져와야 합니다. 그리드 입력 , 뉴런 출력 , 가중치 , 그리드 출력 . 외부에서 접근 가능 그리드의 입력 및 출력은 예제를 제공하고 그리드의 운영 사용을 위한 것입니다. 교육을 위해서는 천칭 자리에 대한 외부 액세스가 필요합니다.
GPU의 계산으로 전송하려면 뉴런 의 출력에 대한 외부 액세스 가 필요합니다. 원칙적으로 데이터 배열은 처음에 외부에 있어야 하고 이미 이러한 외부 데이터가 네트워크에 집계되어야 한다고 생각합니다.

3) 훈련. 나는 네트워크 토폴로지에 의존하지 않는 방법으로 GA의 도움으로 학습하는 경향이 있습니다. 나는 그것을 기초로 삼고 가능하다면 / 필요한 경우 올바른 것에 과부하를 줄 것을 제안합니다.

의제에는 세 가지 작업이 있습니다.

레이어는 한 번의 반복에서 독립적이고 동일한 유형을 갖는 뉴런의 합집합입니다.


 

 

이별은 실제로 매우 현실적입니다.

예를 들어 IEvolvable 인터페이스가 있습니다. 유전학 작업 측면에서 그리드에 대한 인터페이스. 예를 들어 여기에서 당신과 Andrey는 조용히 유전학을 교활하게 잘라 이 인터페이스에 독점적으로 묶을 수 있습니다.

 

그건 그렇고, 다중 상속이 그다지 방해가되지 않는 곳.

________________

설득, 나는 오늘 인터페이스를 줄이려고 노력할 것입니다.

그런데. 프로젝트 관리자는 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에서 계산을 구성하기가 어려울 것입니다.

Xpert의 표현에 대해 이야기 하면 GPU의 작업 부하에 문제가 있습니다.

일반적으로 저는 공식을 타협(통합)하는 경향이 있으며, GPU 부하 문제를 상속하지만 문제가 적습니다.

레이어는 한 번의 반복에서 독립적이고 동일한 유형을 갖는 뉴런의 합집합입니다.

어떤 생각이 드나요?

추신 반대가 있습니까?