Что нужно добавить для дополнительной поддержки универсальных математических расчетов в MQL5 и MQL5 Cloud Network? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Речь немного о другом. Хотелось именно управления ходом оптимизации.
Грубо говоря хочется своей генетики?
Изначально - да, просили для генетики.
А я бы использовал просто для авто-оптимизации (выбирал области параметров исходя из предыдущих результатов).
А я бы использовал просто для авто-оптимизации (выбирал области параметров исходя из предыдущих результатов).
Грубо говоря хочется своей генетики?
В этом направлении но не всё так односложно.
Во первых если бы стандартный ГА удовлетворял во всём (~10К полноценных параметров, многопараметрическая оптимизация) то большая часть из недовольных умолкла бы.
Но есть ещё одна подножка, иногда хочется остановить оптимизацию выбрать фаворитов по какому то наитию, и продолжить дальше. Те вносить ручную коррекцию в автоматическую ФФ.
Если и это будет то даже небольшая часть требовательных пользователь окончательно закроет вопрос с ГА.
И пусть разработчиков не смущает что недовольных мало, обычно это самые продвинутые и именно на них стоит равняться.
ЗЫ Но по факту ты прав, своя генетика ближе к телу, и запускать её в клауде было бы круто. Кстати тогда бы можно было решить и вопрос с валк-форвард тестами своими силами, а не выпрашивать этот режим у MQ.
И пусть разработчиков не смущает что недовольных мало, обычно это самые продвинутые
на самом деле этот фактор есть самый весомый при отказе.
по сути им прийдется отвлекатся на задачу, которую будут использовать узкий круг продвинутых.
на самом деле этот фактор есть самый весомый при отказе.
по сути им прийдется отвлекатся на задачу, которую будут использовать узкий круг продвинутых.
В том то и прикол, продвинутый пользователь видит больше чем новичёк, со временем его видение проблем распространится на других и у них тоже появится желание использовать тот функционал который уже сейчас хочет использовать продвинутый юзер.
Если ориентироваться на основную массу то платформа всегда будет как бы в прошлом.
До того как Кодак создал мыльницу и сеть проявочных машин, желания у туристов самому фоткать небыло, это была прерогатива продвинутых юзеров и специалистов от фотографии (коих было множество возле любой достопримечательности).
Но пришёл новатор и создал новую услугу, тем самым перевернув индустрию, продвинув её в массы.
В том то и прикол, продвинутый пользователь видит больше чем новичёк, со временем его видение проблем распространится на других и у них тоже появится желание использовать тот функционал который уже сейчас хочет использовать продвинутый юзер.
Если ориентироваться на основную массу то платформа всегда будет как бы в прошлом.
До того как Кодак создал мыльницу и сеть проявочных машин, желания у туристов самому фоткать небыло, это была прерогатива продвинутых юзеров и специалистов от фотографии (коих было множество возле любой достопримечательности).
Но пришёл новатор и создал новую услугу, тем самым перевернув индустрию, продвинув её в массы.
Согласный я. С обоими. :)))
Интерфейс надо думать. Что есть кастомная генетика? Если интерфейс с клаудом делать на уровне "SetPopullationForCalc(); GetPopulationFitnessFuncs();" то гибкой и мощной схемы не получится. Лучше бы обмен с клаудом был реализован на уровне пакетов заданий произвольного объёма, когда размер популяции не фиксирован и передаётся в качестве параметра вместе с массивом параметров. Плюс напрашивается полная отвязка (наконец уже!!) "оптимизации" и "тестирования", с предоставлением (параллельно произвольным!) возможностей чередования и комбинирования запросов на (1) массовый облегчённый обсчёт через клауд (аналог оптимизации) массивов наборов параметров с (2) подробными одиночными прогонами (аналог "тестирования"). Тогда и валк-форварды строятся без проблем и всяческая прочая какава с чаем, которая сейчас ещё даже в голову не приходит.
Такие вот мысли.
Отсюда вывод: нужно думать гибкую апи-прослойку между тестером и программами в терминале. Тады и древняя тема "запуска генетической оптимизации в ходе торговли с коррекцией параметров робота на лету" по ходы пьесы может ненавязчиво решиться вместе с прочими. И множество других вкусностей становится возможным. В частности клауд станет вообще супер-универсальным массовым мегакомпьютером, способным решать произвольные задачи с большими объёмами однотипных вычислений.
Для хорошей автооптимизации тестер надо выбрасывать из цепочки.
Я не про авто-оптимизацию советника во время работы, а, например, про волк-форвард своими силами.
Выбор диапазонов параметров для будущих прогонов эту задачу решил бы на 100% (даты можно ограничить программно с помощью тех же параметров).
Но это, с учетом использования клауда, не так просто и однозначно, как кажется.
Я не про авто-оптимизацию советника во время работы, а, например, про волк-форвард своими силами.
Эмм, это то же самое с моей точки зрения :)
Во первых если бы стандартный ГА удовлетворял во всём (~10К полноценных параметров, многопараметрическая оптимизация) то большая часть из недовольных умолкла бы.
Да, бОльшая часть из 5-10 недовольных :)