Собираю команду для развития МО (Дерева решения/леса) применительно к трендовым стратегиям - страница 18
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Значит команда отменяется. )
А будет администрируемая группа. )
Внесение администрирования даже в уже сложившуюся команду, с вероятностью 95 % убивает результат.
А чтобы администрировать то чего еще нет, надо обладать очень мощными козырями. ))
Пора предъявить козыри.
Есть предложение, но нет выражения спроса в какой либо форме.
Если на данном этапе потенциальные участники команды не хотят проявить активность, то я не уверен в их мотивации.
Очень печально.
Без администрирования нельзя двигаться вперед - я предложил схему, где сами участники выбирают направление движения, наиболее комфортных условий представить себе трудно.
Из этого списка даже репу на GitLab не зарегистрировали...
Команду нужно было сразу собирать под лицензию Apache 2.0, а вы хотели незнакомых людей заставить соблюдать кооперативную этику.
Ну, и насяльник вообще ничего не понимает в разработках ПО.
Регистрация - дело минутное, это лишь формальность.
Команда должна работать во благо себе и всем членам команды, а не в носу ковырять по настроению.
Разработка идей и их кодирование разные вещи.
Регистрация - дело минутное, это лишь формальность.
Команда должна работать во благо себе и всем членам команды, а не в носу ковырять по настроению.
Разработка идей и их кодирование разные вещи.
Если "минутное дело", то почему оно не выполнено? Рабочего пространства нет, потому что нет команды. Команды нет, потому что нет рабочего пространства...
И в данной области идею нужно сразу реализовывать, хотя бы в псевдокоде.
Если "минутное дело", то почему оно не выполнено? Рабочего пространства нет, потому что нет команды. Команды нет, потому что нет рабочего пространства...
И в данной области идею нужно сразу реализовывать, хотя бы в псевдокоде.
Команды нет, так-как люди не хотят работать совместно, всем(большинству) интересно послушать идеи других, а для этого как раз подходит формат, предложенный Максимом - чат.
Может на текущем этапе недоверия и страха раскрыть свои граальные идеи это вариант общения по интересам.
Прежде чем делать, надо понимать, как что будет выглядеть в итоге - плановый набросок должен быть, я предложил высказаться людям по вопросы организации рабочего процесса - как они это хотят, как видят, и уже с учетом этих пожеланий организовывать рабочее пространство.
Граждане - всё в наших руках!
Рынок не место для решения личных психологических проблем, а поле для извлечения дохода!
В одиночку не сдвинуть эту махину.
Так, что-то все смешалось - движок для форума многофункциональный? Про REST почитал, но это голая архитектура, под неё надо искать исходники форума?
Что значит можно проигрывать другие скрипты, где проигрывать? Представьте, что хотите продать продукт простому юзеру и объясните по человечески, что это дает и с чем это идят, пожалуйста. Думаю, что это нужно и важно, но не понимаю, зачем, спасибо.
А что тут объяснять, выше я показал вам пример как из MQL скрипта обратиться к установленному на локальном компьютере питону, обучить нейросетевую модель, сохранить ее в файл, загружать ее и работать с ней, вызывая метод Predict.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
По этому же образцу вы можете создать любую из сотен доступных в библиотеках питона моделей МО и обучить ее на своих данных. По этому же образцу можно создать клиентскую часть, в советнике или индикаторе, которая при инициализации будет загружать файл модели, а затем потиково или побарово опрашивать ее вызовом метода Predict со своими, текущими данными.
Поддержка протоколов NamedPipes и REST позволяет указанным скриптам, советникам или индикаторам работать без DLL с моделями МО, как на локальном компьютере так и удаленно в сети.
В отличие от NamedPipes при использовании REST текст скрипта из MQL нужно посылать не через FileWriteString, а через WebRequest на доступный в сети, публичный URL, например на VPS где запущен движок, в остальном все аналогично.
А что тут объяснять, выше я показал вам пример как из MQL скрипта обратиться к установленному на локальном компьютере питону, обучить нейросетевую модель, сохранить ее в файл, загружать ее и работать с ней, вызывая метод Predict.
https://www.mql5.com/ru/forum/261479/page16#comment_8011085
По этому же образцу вы можете создать любую из сотен доступных в библиотеках питона моделей МО и обучить ее на своих данных. По этому же образцу можно создать клиентскую часть, в советнике или индикаторе, которая при инициализации будет загружать файл модели, а затем потиково или побарово опрашивать ее вызовом метода Predict со своими, текущими данными.
Поддержка протоколов NamedPipes и REST позволяет указанным скриптам, советникам или индикаторам работать без DLL с моделями МО, как на локальном компьютере так и удаленно в сети.
В отличие от NamedPipes при использовании REST текст скрипта из MQL нужно посылать не через FileWriteString, а через WebRequest на доступный в сети, публичный URL, например на VPS где запущен движок, в остальном все аналогично.
В общем понятно, инструмент для активации рассчитанной модели.
Но я так и не понял, как дела с оптимизатором стратегий...
Оставлю мысли по деревьям, вдруг пригодятся.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Машинное обучение в трейдинге: теория и практика (торговля и не только)
Aleksey Vyazmikin, 2018.07.10 14:18
Вчера пришла в голову мысль, а почему ищут деревья решений, т.е. модель описывающую сущность? Т.е. зачем нам описывать всю сущность вообще, может надо просто искать те куски этой сущности, которые наиболее понятны и предсказуемы? Это я думал в том ключе, что раз я коллекционирую листья от деревьев, то быть может мне и надо именно использовать метод для поиска таких листьев без построения полного дерева решений, что должно, по моему пониманию, дать прирост качества за одно и то же потраченное вычислительное время.
Сунулся я в интернет и не вижу нигде подобного метода. Может кто знает, о таких наработках?
Пока придумываю алгоритм, думаю, что первым делом надо выделить предикторы, в которых выделяется предсказательная способность одного из классов, при этом предикторы видимо надо сделать бинарными (для этого придется формировать свою выборку под каждый предиктор или составлять диапазоны исключения из общей выборки (что более рационально?)). Потом уже использовать отобранные предикторы (и их комбинации) для построения пеньков под конкретный класс (в моем случае 3 класса), а уже на эти пеньки наращивать оставшиеся предикторы. При этом можно их так же проверять на предпочтение определенного класса. Тогда, по идеи, мы найдем области наиболее поддающиеся классификации под конкретные целевые. А оставшаяся область - это будет просто поле бездействия/ожидания.
Конечно, можно потом посмотреть где листья наслоились друг на друга и сделать в этих случаях усредненный результат. Да и подобие дерева можно таким образом построить потом, но уже с элементами голосования из-за плотности в разных областях разных целевых.
Что думаете об этой идеи?
Оставлю мысли по деревьям, вдруг пригодятся.
Вот многие тут высказывают мысли - идеи, некоторые предлагают механизмы - алгоритмы и даже иногда доходит до реализации - готовых программ, но к сожалению нет продвижения, практических результатов, в основном все заканчивается флудом и необоснованными декларациями.
Возможно это потому, что у нас нет унифицированного представления средств МО для трейдинга - формата данных, моделей и объективной оценки результатов работы, что не позволяет нам конструктивно общаться между собой, обмениваться результатами экспериментов и делать обоснованные выводы.
И какой смысл в такой ситуации имеет собираемая вами команда по развитию МО, если мы не имеем методов объективной оценки даже индивидуального исполнителя - развивателя?))
Может начать с создания и согласования таких методов, в ветке по МО была попытка поднять этот вопрос, но пока не нашлось взаимопонимания, возможно у вас, как у энтузиаста этой темы, что-нибудь получится?
Вот многие тут высказывают мысли - идеи, некоторые предлагают механизмы - алгоритмы и даже иногда доходит до реализации - готовых программ, но к сожалению нет продвижения, практических результатов, в основном все заканчивается флудом и необоснованными декларациями.
Возможно это потому, что у нас нет унифицированного представления средств МО для трейдинга - формата данных, моделей и объективной оценки результатов работы, что не позволяет нам конструктивно общаться между собой, обмениваться результатами экспериментов и делать обоснованные выводы.
И какой смысл в такой ситуации имеет собираемая вами команда по развитию МО, если мы не имеем методов объективной оценки даже индивидуального исполнителя - развивателя?))
Может начать с создания и согласования таких методов, в ветке по МО была попытка поднять этот вопрос, но пока не нашлось взаимопонимания, возможно у вас, как у энтузиаста этой темы, что-нибудь получится?
Согласен, что стандартные оценки не годятся, я ранее об этом писал. Это особенно очевидно, если речь идет о трендовой стратегии. Искать оптимальные критерии оценки лучше на какой либо базовой стратегии, а потом уже портировать наработки на другие стратегии. В ветке про МО в основном пытаются предсказать как закроется бар на его открытии, как я понял. И там может ещё подойти метрика угадал/не угадал, но даже там, не говоря уже о трендовых стратегиях, надо в оценке учитывать и пункты.
Вот на рисунке ниже в квадрате под номером 1 входы на продажу будут значительно лучше (принесут больше прибыли), чем в квадрате 2, где так же будет прибыль, а вот уже в квадрате 3 будет закрытие с убытком при продаже актива, но и прибыли это не принесет при покупке актива, пока не сформируется минимальная цена.
Таким образом видно, что угадывание входов в процентах может быть большим, но если это большое значение в большей мере сосредоточено во втором квадрате, а не в первом, то меньшее значение ошибок может перекрывать всю прибыль.
Поэтому я сейчас хочу учитывать в оценке своей модели сосредоточение сигналов, в какой области они больше дают прибыль или убыток и учитывать это при построении дерева решений.