"Новый нейронный" - проект Open Source движка нейронной сети для платформы MetaTrader 5. - страница 49
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
У кого есть опыт работы в команде над большим проектом?
Подразумевается также опыт работы с VCS.
Вообще, насколько я могу понять, наметился некий тупичок - здесь, в-основном, все самостоятельные птицы, способные в одиночку решать любые проблемы (начиная от самостоятельного изучения языка и заканчивая описанием сложной логики торговли). А лебедя, рака и щуку при всех их сильных качествах в одну повозку впрячь, конечно, можно, но хватит их только на 50 страниц активных обсуждений в этой ветке форума..
Сейчас дело стало за тем, что у проекта должен быть лидер, который:
Если МК не проявят активности в ближайшие пару недель, проект можно будет сворачивать, или переносить в коммерческое русло и в другое место.
Ибо без контроля МК проект как опенсорс теряет смысл.
Вообще, насколько я могу понять, наметился некий тупичок - здесь, в-основном, все самостоятельные птицы, способные в одиночку решать любые проблемы (начиная от самостоятельного изучения языка и заканчивая описанием сложной логики торговли). А лебедя, рака и щуку при всех их сильных качествах в одну повозку впрячь, конечно, можно, но хватит их только на 50 страниц активных обсуждений в этой ветке форума..
Сейчас дело стало за тем, что у проекта должен быть лидер, который:
В целом, всё верно сказал. Каждый из нас способен сделать этот проект самостоятельно.
Но как обычно дьявол кроется в деталях.
По материалам 50 страниц штурма можно подытожить что идеи есть и из них можно составить вполне вменяемый план атаки.
Хотя большинство индивидуалы, но работать в команде никто явно не сопротивляется. Всё таки командная работа позволяет распараллелить задачи, что ускорит весь проект.
И тут начинаются детали: командная работа в классическом понимании предполагает что исполнитель получает задание и выполнит его в установленные сроки. Тогда можно будет из единого центра планировать продвижение проекта и раздавать задания исполнителям. По факту же исполнители заняты своими делами и концентрировать всё время на опенсорсе проекте не могут. Отсюда неизбежно появится дисбаланс в развитии проекта.
Думаю выходом может стать доска объявлений где руководитель будет выставлять задания а исполнители будут брать что им по силам и отчитываться о продвижении и сроках окончания. Если ТЗ будет чётко формализовано проект будет закончен раньше чем начнётся :)
И ещё одна деталь, хотелось бы иметь список общепринятых наименований переменных и методов, не то чтобы это принципиально, но будет проще если будет стандартизовано. Хотя конечно сложно составить такой список, но какие то общие принципы создания имён выработать (либо позаимствовать) можно.
Если МК не проявят активности в ближайшие пару недель, проект можно будет сворачивать, или переносить в коммерческое русло и в другое место.
Ибо без контроля МК проект как опенсорс теряет смысл.
Во истину глаголишь.
ЗЫ как минимум двоим, из нас с тобой, по силам сделать всё самостоятельно.
ЗЗЫ и как ты правильно сказал, индивидуальная разработка это уже коммерческая разработка.
Раз время потрачено а исходники только у одного то вывод прост.
Ладно, пока идёт поиск деда мороза,
выложу весь мусор что наковырял в своих мозгах, может из этого можно будет составить хоть какое то ТЗ.
Движёк сетки
1. инициализация сетки
2. рабочий ход сетки
3. обучение сетки
1) топологию сетки можно задавать бинарными полями
подробнее тут http://cgm.computergraphics.ru/content/view/25 раздел 7.Прямое кодирование
Разделение на грамматики или прямое кодирование это уже надстройка над методом инициализации, всё равно в конце всё сводится к прямому кодированию.
Таком образом сами топологии (а это львиная доля трудностей в задании сети) сводятся к написанию методов составления таблицы прямого кодирования.
В статье пишется что нельзя задать обратные связи, но если по каждому рангу операторов задержки создать свою матрицу связей то проблема исчезает (правда матрица будет полной а не треугольной как при нулевой задержке).
Получается что надстройка над методом прямого кодирования должна знать какой ранг задержки использует сеть.
Типы нейронов так же должны быть заданы в надстройке (вот этот момент у меня ещё не проработан, не уверен нужно ли жёстко прописывать и перегружать типы нейронов или их задавать какими то более либеральными методами) ???
Можно пока остановиться на перегрузке жёстких типов и если будет метод мягкого кодирования добавить его как один из перегружаемых.
2) Рабочий ход обусловлен прописанными связями (с помощью агрегации данных) и типами нейронов, это я выкладывал на 5 стр. При этом наружу должны быть выносимы 4 массива данных: Входы сетки, Выходы нейронов, Веса, Выходы сетки. Возможность наружного доступа Входы и Выходы сетки нужны для подачи примеров и для рабочего использования сетки. Наружный доступ к Весам нужен для обучения. Наружный доступ к Выходы нейронов нужен для передачи на расчёт в GPU. В принципе думаю массивы данных изначально должны быть наружными, и уже эти наружные данные агрегировать в сеть.
3) Обучение. Я склоняюсь к обучению с помощью ГА, как к методу не зависящему от топологии сети, предлагаю его взять за основу и при возможности/необходимости перегружать на нужный.
те на повестке дня три задачи.
Слой это объединение нейронов не зависимых на одной итерации и имеющих один тип.
Разделение на самом деле очень даже реально.
Например есть интерфейс IEvolvable. Интерфейс для сетки со стороны работы с генетикой. И вот например вы с Андреем можете спокойно потихоньку пилить генетику, завязываясь исключительно на этот интерфейс.
Вот кстати где бы очень не помешало множественное наследование.
________________
Уговорили, постараюсь сегодня интерфейсы запилить.
Кстати. Манагером проекта может быть gpwr. Частично могу я.
В принципе, можно начинать проект.
Это так напоминалка для себя и других по типам связывания данных.
В задаче рабочего хода есть ньюанс, тк медоды обработки данных зависят от типа нейрона то они должны быть частью объекта типа нейрон.
Ньюанс же заключается в том что считать слоем. Если такую формулировку что давал я то будет затруднительно организовать расчёт в GPU.
Если же остановиться на формулировке TheXpert то будут проблемы с загруженностью GPU.
В целом я склоняюсь к компромисной(объединяющей) формулировке , с ней меньше проблем, хотя она и наследует проблему загруженности GPU.
Слой это объединение нейронов не зависимых на одной итерации и имеющих один тип.
Какие есть мысли?
PS есть какие нибудь против?