"Новый нейронный" - проект Open Source движка нейронной сети для платформы MetaTrader 5. - страница 62
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Что быстрее это понятно. Но сколько раз за всё обучение придется писать в файл? - один раз?
Поэтому тут скорость не критична, зато упрощён визуальный контроль.
Я бы не сказал что xml-файл будет легко визуально контролировать.
какой то шаблон ещё можно в виде xml-файла, но визуализировать сетку с 1500 нейронов в одном слое выйдет полная лабуда, получается имеем геморой с созданием xml а визуализации всё равно нормальной не добиться. Хотя я не отвергаю, можно при сохранении делать дубликат и в xml.
Тут у меня вопросы есть. Что понимать под инициализацией. Если загрузку весов - это одно. Ежели конфигурирование сетки + загрузка весов -- совсем другое.
--
Щас. Спою.
Есть два пути отображения промежуточного представления конфигурации (структуры, типа) сети в код на mql5.
Первый : динамическое конфигурирование сети в процессе инициализации из библиотечных классов. Такая сеть изобилирует динамическими массивами и связями через указатели. Этот подход до сих пор неявно доминировал.
Но есть второй путь : Генерировать жёсткую сетку (со статическими массивами и прямыми обращениями по нужным адресам (индексам)) после предварительного конфигурирования и отображения в xml.
Такой движок может быть гораздо привлекательней для юзеров в силу большего (значительно) быстродействия сгенерированной сетки. Но посложней в исполнении. Фактически нужно будет делать компилятор xml2mql.
Я, собсно, за второй путь. Надеюсь, метаквоты помогут, ежли забуксуем.
Первый путь.
Вторая альтернатива была отброшена накорню(не помню точно но на первых страницах), тк в перспективе в разряд "пользователь" будут зачислены люди не знающие что такое F7.
К тому же подразумевается что движёк будет легко расширяемый, я всяк кто знает назначение F7 может дописать для себя ещё какой то тип сетки или изобрести свой.
ЗЫ понимаю твою привязанность к шаблонному кодированию, но согласись во втором пути будем иметь большие проблемы с реализацией как алгоритмов обучения так и расширением типов нейронов, плюс это всё ещё нужно будет оптимизировать под GPU. Тут в с первым вариантом то серьёзные проблемы, самые простые вещи все умеют, а просто описать проект универсального движка мозк дымит.
Завтра с рабочего компьютера скопирую сюда свои наработки по хранению прототипов сетей, постановки задач обучения, хранения найденных решений
Все в xml
Ресурсоемкость распарсивания xml-файлов на мой взгляд слишком преувеличена
Не следует забывать, что это разовая процедура
Более того написать нативный для MQL5 парсер xml-файлов - это тривиальная задача по сравнению со сложностью нейросетевого проекта
Первый путь.
Вторая альтернатива была отброшена накорню(не помню точно но на первых страницах), тк в перспективе в разряд "пользователь" будут зачислены люди не знающие что такое F7.
К тому же подразумевается что движёк будет легко расширяемый, я всяк кто знает назначение F7 может дописать для себя ещё какой то тип сетки или изобрести свой.
Тут у меня только один вопрос остался. Из за недостаточной компетентности в типологии сетей.
1. Может ли любой тип сетки однозначно определяться с помощью таблицы связей? В смысле, можно ли создать универсальную абстрактную сеть, в которой её тип просто следует из заданной таблицы связей? Другими словами - реально универсальную сеть?
Если ответ положительный - то тип сетки задаётся редактором конфигурации сети ДО создания промежуточного представления, и при этом никакой модификации универсальной библиотеки не требуется. В смысле никогда не потребуется (если она не глючная), какова бы ни была структура сети. Можно, разве что заниматься её оптимизацией, наращиванием библиотеки нелинейных преобразователей, методов обучения и т.п.
Если ответ отрицательный - тогда тыкните носом, плиз, в какую-нибуть ссыль, для ознакомления с исключениями, которые не влазят в такой подход.
--
Теперь про альтернативы. Если xml-представление описания сети тщательно продумать и полность абстрагировать от mql-реализации (что есть правильно), тогда альтернативы не выглядят противоречащими друг-другу. Их можно реализовывать не только обе, но и скрещивать, при случае, промеж собой.
...
Ответ не бинарный,
с одной стороны ответ отрицательный, таблица связей сама по себе не задаёт типизацию нейронов.
С другой стороны ответ положительный, задание типов вполне реализуемо в числовом виде (создаёшь свичём объект конкретного типа наследуемого от общего предка).
Так что в совокупности, параметрический массив и таблица связей вполне подходят.
Но с другой стороны даже редактор конфигураций имеет параметры (количество слоёв, количество нейронов в каждом слое, типы нейронов в слое) и это ещё до создания связей.
Другими словами - реально универсальную сеть?
Из feed-forward да. Для остальных надо смотреть топологию.
Дык топология ж задаётся таблицей связей....
?
Дык топология ж задаётся таблицей связей....
И функционалом связываемых частей.
Ок. Давай тут чуть подробнее.
Этот функционал может быть задан конечной (небольшой) таблицей? Чем отличаются нейроны разных типов (кроме функций активации)?
Ок. Давай тут чуть подробнее.
Этот функционал может быть задан конечной (небольшой) таблицей? Чем отличаются нейроны разных типов (кроме функций активации)?
Если строго, нет.
Сначала простой случай. Есть у нас допустим линейный, сигмоидный, тангенсный нейроны. Если мы хотим добавить новый вид активации, мы вынуждены расширять перечислений видов активаций.
В принципе как бы ну и хрен с ним. Но во-первых зачем например в сети кохонена выходному слою знак о каких=то там функциях активации? Это лишняя, избыточная информация.
Во-вторых этот список теоретически не ограничен.
В-третьих, у каждой сети могут быть особенности в работе и устройстве. Например, у сети Кохонена (SOM) это могут быть настройки функции соседей и флаг, выдавать ли результаты как выход или только лидера (обнуление всех не лидеров)
В логических моделях, например, настраиваемые параметры находятся в функции активации. Это тоже в общую модель?
У слоя MLP это может быть флаг наличия единичного нейрона.
____________________________
Кстати хml намного легче проверить на валидность, чем бинарное представление. И сохранение\восстановление по сути не является критичным по времени.
1. Если строго, нет.
Сначала простой случай. Есть у нас допустим линейный, сигмоидный, тангенсный нейроны. Если мы хотим добавить новый вид активации, мы вынуждены расширять перечислений видов активаций.
В принципе как бы ну и хрен с ним. Но во-первых зачем например в сети кохонена выходному слою знак о каких=то там функциях активации? Это лишняя, избыточная информация.
Во-вторых этот список теоретически не ограничен.
В-третьих, у каждой сети могут быть особенности в работе и устройстве. Например, у сети Кохонена (SOM) это могут быть настройки функции соседей и флаг, выдавать ли результаты как выход или только лидера (обнуление всех не лидеров)
В логических моделях, например, настраиваемые параметры находятся в функции активации. Это тоже в общую модель?
У слоя MLP это может быть флаг наличия единичного нейрона.
____________________________
2. Кстати хml намного легче проверить на валидность, чем бинарное представление. И сохранение\восстановление по сути не является критичным по времени.
1. Почему бы и нет. У меня идея примерно такова - создать универсальную "элементную базу", из которой может быть "спаяна" нейросетка любого типа (вполне может быть расширяемой). Элементы в этой базе задаются точными однозначными определениями-формулировками. Если нужно с применением псевдокода. Но не в виде mql-кода, чтобы обеспечить отвязку от реализаций - они могут со временем совершенствоваться. После того как абстрактная элементная база создана (если получится), можно городить формат xml-файла, способного описать все связи между элементами сети. После утверждения xml-описания проект легко может быть распараллелен: отдельно пишутся
1) реализации элементов. => на выходе - библиотека компонентов.
2) конфигуратор(ы) типа/структуры сети => на выходе - графический, пошаговый или ещё какой конфигуратор(ы), сохраняющий конфигурацию в xml-файл.
3) транслятор(ы) в mql-код. => на выходе либо (1) супер-пупер-самоконфигурирующаяся mql-нейросеть, берущая в качестве параметра xml-файл, либо (2) компилятор в конкретную жёсткую сеть на mql.
Как-то так. Вроде складно получается.
2. Ага.