"Новый нейронный" - проект Open Source движка нейронной сети для платформы MetaTrader 5. - страница 49

Новый комментарий
 
TheXpert:

У кого есть опыт работы в команде над большим проектом?

Подразумевается также опыт работы с VCS.

Вообще, насколько я могу понять, наметился некий тупичок  - здесь, в-основном, все самостоятельные птицы, способные в одиночку решать любые проблемы (начиная от самостоятельного изучения языка и заканчивая описанием сложной логики торговли). А лебедя, рака и щуку при всех их сильных качествах в одну повозку впрячь, конечно, можно, но хватит их только на 50 страниц активных обсуждений в этой ветке форума..

Сейчас дело стало за тем, что у проекта должен быть лидер, который:

  • во-первых, будет заинтересован в конечной цели проекта, 
  • во-вторых, будет способен разбить проект на этапы, задачи и подзадачи, которые любой программист в этой ветке сумел бы записать на себя и сделать в разумные сроки. При этом задачи и подзадачи желательно делать контекстно-независимыми, т.е. максимально абстрагировать от прочего кода.
  • в-третьих, должен будет держать руку на пульсе проекта, знать, какие части и насколько готовы; возможно ли осуществить интеграцию решенных подзадач в решение задачи целиком.
Идеальным вариантом, наверное, будет человек из MetaQuotes, обладающий подобным опытом, + будет повод опробовать систему TeamWox применительно к MQL-сообществу, тем более, что Ренат об этом как-то уже говорил.

 

Если МК не проявят активности в ближайшие пару недель, проект можно будет сворачивать, или переносить в коммерческое русло и в другое место.

Ибо без контроля МК проект как опенсорс теряет смысл.

 
Vladix:

Вообще, насколько я могу понять, наметился некий тупичок  - здесь, в-основном, все самостоятельные птицы, способные в одиночку решать любые проблемы (начиная от самостоятельного изучения языка и заканчивая описанием сложной логики торговли). А лебедя, рака и щуку при всех их сильных качествах в одну повозку впрячь, конечно, можно, но хватит их только на 50 страниц активных обсуждений в этой ветке форума..

Сейчас дело стало за тем, что у проекта должен быть лидер, который:

  • во-первых, будет заинтересован в конечной цели проекта, 
  • во-вторых, будет способен разбить проект на этапы, задачи и подзадачи, которые любой программист в этой ветке сумел бы записать на себя и сделать в разумные сроки. При этом задачи и подзадачи желательно делать контекстно-независимыми, т.е. максимально абстрагировать от прочего кода.
  • в-третьих, должен будет держать руку на пульсе проекта, знать, какие части и насколько готовы; возможно ли осуществить интеграцию решенных подзадач в решение задачи целиком.
Идеальным вариантом, наверное, будет человек из MetaQuotes, обладающий подобным опытом, + будет повод опробовать систему TeamWox применительно к MQL-сообществу, тем более, что Ренат об этом как-то уже говорил.

В целом, всё верно сказал. Каждый из нас способен сделать этот проект самостоятельно.

Но как обычно дьявол кроется в деталях.

По материалам 50 страниц штурма можно подытожить что идеи есть и из них можно составить вполне вменяемый план атаки.

Хотя большинство индивидуалы, но работать в команде никто явно не сопротивляется. Всё таки командная работа позволяет распараллелить задачи, что ускорит весь проект.

И тут начинаются детали: командная работа в классическом понимании предполагает что исполнитель получает задание и выполнит его в установленные сроки. Тогда можно будет из единого центра планировать продвижение проекта и раздавать задания исполнителям. По факту же исполнители заняты своими делами и концентрировать всё время на опенсорсе проекте не могут. Отсюда неизбежно появится дисбаланс в развитии проекта.

Думаю выходом может стать доска объявлений где руководитель будет выставлять задания а исполнители будут брать что им по силам и отчитываться о продвижении и сроках окончания. Если ТЗ будет чётко формализовано проект  будет закончен раньше чем начнётся :)

И ещё одна деталь, хотелось бы иметь список общепринятых наименований переменных и методов, не то чтобы это принципиально, но будет проще если будет стандартизовано. Хотя конечно сложно составить такой список, но какие то общие принципы создания имён выработать (либо позаимствовать) можно.

 
TheXpert:

Если МК не проявят активности в ближайшие пару недель, проект можно будет сворачивать, или переносить в коммерческое русло и в другое место.

Ибо без контроля МК проект как опенсорс теряет смысл.

Во истину глаголишь.

ЗЫ как минимум двоим, из нас с тобой, по силам сделать всё самостоятельно.

ЗЗЫ и как ты правильно сказал, индивидуальная разработка это уже коммерческая разработка.

Раз время потрачено а исходники только у одного то вывод прост.

 

Ладно, пока идёт поиск деда мороза,

выложу весь мусор что наковырял в своих мозгах, может из этого можно будет составить хоть какое то ТЗ.

 Движёк сетки
 1. инициализация сетки
 2. рабочий ход сетки
 3. обучение сетки
 
 1) топологию сетки можно задавать бинарными полями
 подробнее тут http://cgm.computergraphics.ru/content/view/25     раздел 7.Прямое кодирование
 
 Разделение на грамматики или прямое кодирование это уже надстройка над методом инициализации, всё равно в конце всё сводится к прямому кодированию.
     Таком образом сами топологии (а это львиная доля трудностей в задании сети) сводятся к написанию методов составления таблицы прямого кодирования.
 В статье пишется что нельзя задать обратные связи, но если по каждому рангу операторов задержки создать свою матрицу связей то проблема исчезает (правда матрица будет полной а не треугольной как при нулевой задержке).
 Получается что надстройка над методом прямого кодирования должна знать какой ранг задержки использует сеть.
     Типы нейронов так же должны быть заданы в надстройке (вот этот момент у меня ещё не проработан, не уверен нужно ли жёстко прописывать и перегружать типы нейронов или их задавать какими то более либеральными методами) ???
 Можно пока остановиться на перегрузке жёстких типов и если будет метод мягкого кодирования добавить его как один из перегружаемых.
 
 2) Рабочий ход обусловлен прописанными связями (с помощью агрегации данных) и типами нейронов, это я выкладывал на 5 стр. При этом наружу должны быть выносимы 4 массива данных: Входы сетки, Выходы нейронов, Веса, Выходы сетки. Возможность наружного доступа Входы и Выходы сетки нужны для подачи примеров и для рабочего использования сетки. Наружный доступ к Весам нужен для обучения. Наружный доступ к Выходы нейронов нужен для передачи на расчёт в GPU. В принципе думаю массивы данных изначально должны быть наружными, и уже эти наружные данные агрегировать в сеть.
 

 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 есть какие нибудь против?

1...424344454647484950515253545556...100
Новый комментарий
Причина обращения: