Машинное обучение в трейдинге: теория, модели, практика и алготорговля - страница 2915
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Может пора уже двигать тему МО? Делать исследования, делиться мыслями, читать что то? Обсуждать...
Твой возглас тоже очень сильно помогает теме..в точности соответствует текущему положению дел и решительно двигает МО в массы :-)
"что ты сделал для хип-хопа ?" (с)
раз уж ты сильно в курсе МО и происходившего на ветке - дал бы краткое резюме ветке (или эпитафию ей) со ссылками на первоисточники и где чего двигал
Он сам же ушел.
У него ник зачёркнут, как при бане, а не заменён надписью [Удален]
Так тема то сдулась, уже давно нет ничего нового, ни мыслей, ни статей.
Думаю, проблема не в людях, народ тут продвинутый, а в политике MQ. Они решили, что само сростется - надо только инструментов накидать и не вмешиваться и оно как попрет само...
А оно не прет. Если и рождаются решения, то никто на простом энтузиазме делится не будет, дураков нет.
MQ явно пытаются повторить успех индикаторов, когда достаточно было создать условия и народ нафигачил 3000 индикаторов. В теме МО так не получится, тут уровень разработки совсем другой и стоимость работающих решения несравнима с индикаторами.
MQ придется баблос в эту тему вкладывать и брать разработку в свои руки. Им надо выпустить свое решение и интегрировать его в MT5, другого пути нет. Это дорого и рискованно, но МО так или иначе все равно придет в трейдинг.
Майкрософт в 2018 вложился в OpenAI, а Гугл надувал щеки и занимался созданием инструментов для народа (TensorFlow). Теперь писают кипятком и думают как спасать от ChatGPT свой поисковый бизнес. Почему то ChatGPT не родился на халяву на форумах ))
А оно и не будет переть.
Например исследую модели разными алгоритмами МО.
И у разных алгоритмов структура конечной модели в коде разная.
Например в нелинейной регрессии, запись формулы получается длиной 900 символов.
А в GBoosting код конечной модели достигает 15 000 строк! Сколько там символов получается, трудно представить.
Так вот проблема софта, а именно окно Формула синтетического инструмента, не позволяет ввести большое количество символов.
Там в окне Формула синтетического инструмента, ограничена длина ввода очень малым количеством вводимых символов.
Как исследовать и проверять модели МО выраженные через формулу, не понятно. Как оно будет переть?
Инструмент вроде и есть, но ограничивает в разработке. От сюда нет ни какой производительности труда, по проверке моделей.
А их надо перелопатить сотни. И каждую модель оформлять кодом в скрипте, очень не продуктивно из-за большой обвязки сопутствующего окружения,
чтоб потом просто выкинуть этот код, если модель не удачна.
Так же предложил разработчикам ввести для Формул синтетического инструмента, пользовательские функции.
Чтоб можно было оборачивать любой тип модели в пользовательскую функцию, и использовать её в Формуле синтетического инструмента.
Тем самым решается вопрос, как с длиной модели, так и с её структурой в виде кода.
Но разработчики ответили, что не планируют изменения в кастомных символах.
Как оно будет переть?
Если для продуктивного профессионального исследования есть такие ограничения.
У него ник зачёркнут, как при бане, а не заменён надписью [Удален]
Ну, я помню, что он так тут заявил делал заявление в этом ключе - модераторы потерли. Думаю, ещё месяц не прошел.
А оно и не будет переть.
Например исследую модели разными алгоритмами МО.
И у разных алгоритмов структура конечной модели в коде разная.
Например в нелинейной регрессии, запись формулы получается длиной 900 символов.
А в GBoosting код конечной модели достигает 15 000 строк! Сколько там символов получается, трудно представить.
Так вот проблема софта, а именно окно Формула синтетического инструмента, не позволяет ввести большое количество символов.
Там в окне Формула синтетического инструмента, ограничена длина ввода очень малым количеством вводимых символов.
Как исследовать и проверять модели МО выраженные через формулу, не понятно. Как оно будет переть?
Инструмент вроде и есть, но ограничивает в разработке. От сюда нет ни какой производительности труда, по проверке моделей.
А их надо перелопатить сотни. И каждую модель оформлять кодом в скрипте, очень не продуктивно из-за большой обвязки сопутствующего окружения,
чтоб потом просто выкинуть этот код, если модель не удачна.
Так же предложил разработчикам ввести для Формул синтетического инструмента, пользовательские функции.
Чтоб можно было оборачивать любой тип модели в пользовательскую функцию, и использовать её в Формуле синтетического инструмента.
Тем самым решается вопрос, как с длиной модели, так и с её структурой в виде кода.
Но разработчики ответили, что не планируют изменения в кастомных символах.
как оно будет переть?
Если для продуктивного профессионального исследования есть такие ограничения.
Вы о каких алгоритмах, моделях и языке программирования говорите??
Вы о каких алгоритмах, моделях и языке программирования говорите??
Алгоритмы обычные: разные виды регрессии/классификации. Или деревья GBoosting, RandomForest.
Эти алгоритмы строят разные по структурному виду модели.
Если брать регрессионные модели, то структура модели не такая большая получается, и выглядит как линейная формула с математическими операциями.
Но и она не вмещается в окно Формула синтетического инструмента. Из-за ограничения вводимых символов в окно.
А если брать модели на деревьях, то там уже модель получается на switch конструкциях. Одна switch конструкция - одно дерево.
И чем больше использовано деревьев в модели, тем больше в ней содержится switch конструкций.
Тем самым код модели для этого алгоритма, может разрастаться до десятков тысяч строк кода.
И чтоб была продуктивность в проверке сотней моделей любого алгоритма, не описывая их через MQL5 скрипт, с обвязкой окружения MQL5 кода
было предложено разработчикам ввести пользовательские функции в окне Формула синтетического инструмента.
К сожалению не услышали. Вернее услышали, но сослались на то, что в Формуле синтетического инструмента, изменений не планируют.
И возможно, когда-то в будущем, может и рассмотрят предложение. В чём я сомневаюсь.
А модели проверять надо сейчас, вот и приходится тянуть всю обвязку окружения MQL5 кода через скрипт MQL5.
Что существенно замедляет продуктивность в проверке моделей в МТ5.
Что имеется ввиду под продуктивностью проверки?
Гораздо быстрее обернуть код модели в пользовательскую функцию, и сохранить в какой нибудь файл или специализированное окно,
и ввести формулу синтетического инструмента, используя созданную пользовательскую функцию с моделью, и быстро её проверить,
с учётом авто синхронизации разных инструментов если это требуется. Чем описывать эту модель с многословной MQL5 обвязкой в коде скрипта.
Языки C и MQL5.
Алгоритмы обычные: разные виды регрессии/классификации. Или деревья GBoosting, RandomForest.
Эти алгоритмы строят разные по структурному виду модели.
Если брать регрессионные модели, то структура модели не такая большая получается, и выглядит как линейная формула с математическими операциями.
Но и она не вмещается в окно Формула синтетического инструмента. Из-за ограничения вводимых символов в окно.
А если брать модели на деревьях, то там уже модель получается на switch конструкциях. Одна switch конструкция - одно дерево.
И чем больше использовано деревьев в модели, тем больше в ней содержится switch конструкций.
Тем самым код модели для этого алгоритма, может разрастаться до десятков тысяч строк кода.
И чтоб была продуктивность в проверке сотней моделей любого алгоритма, не описывая их через MQL5 скрипт, с обвязкой окружения MQL5 кода
было предложено разработчикам ввести пользовательские функции в окне Формула синтетического инструмента.
К сожалению не услышали. Вернее услышали, но сослались на то, что в Формуле синтетического инструмента, изменений не планируют.
И возможно, когда-то в будущем, может и рассмотрят предложение. В чём я сомневаюсь.
А модели проверять надо сейчас, вот и приходится тянуть всю обвязку окружения MQL5 кода через скрипт MQL5.
Что существенно замедляет продуктивность в проверке моделей в МТ5.
Что имеется ввиду под продуктивностью проверки?
Гораздо быстрее обернуть код модели в пользовательскую функцию, и сохранить в какой нибудь файл или специализированное окно,
и ввести формулу синтетического инструмента, используя созданную пользовательскую функцию с моделью, и быстро её проверить,
с учётом авто синхронизации разных инструментов если это требуется. Чем описывать эту модель с многословной MQL5 обвязкой в коде скрипта.
Языки C и MQL5.
Это не чат ботом сгенерировано? Очень похоже. Не в обиду будет сказано.
У момента цены есть три измерения - значение цены, время и обьем.
Обьем- это сгусток цены?
У момента цены есть три измерения - значение цены, время и обьем.
Обьем- это сгусток цены?