Немного удивлен :) Решил поделиться и задать НЕ риторический вопрос. - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Оптимизатор не совсем "линейно масштабированный тестер", а имеет свои методы оптимизации, работающие эффективно на масштабных повторяющихся расчетах.
Мы как раз сейчас заняты ускорением на массовых расчетах. Вот ссылка на прошлые результаты, а уже готова новая версия с более скоростными расчетами.
Согласен, не совсем "линейно масштабированный тестер". Вы проводите явные оптимизации, что есть очень хорошо. Однако, я не представляю, как вы будете оптимизировать для унивесрального случая очень частую ситуацию:
Оптимизация идет по двум параметрам, один параметр (диапазон 100 значений) не касается вызовов индикатора, второй (диапазон 5 значений)- касается.
В таком случае при переборе 500 вариантов вы 500 раз вычислите значения индикатора. При этом на самом деле произведете огромное количество повторных вычислений. Потому что диапазон второй переменной всего 5, а не 500.
Это просто простейший пример привел. Возможно, у вас уже есть какие-то задумки, как обойти подобную линейную масштабируемость тестера для оптимизатора.
P.S. Именно на подобных примерах получается преимущество своих считалок в скорости не на проценты, а на порядки. Но эти считалки не универсальны, поэтому сравнение некорректно изначально.
Ок - допустим есть оптимизатор который без облачного вычисление, но многопоточный, и который поддерживает С++ и МТ4 (и всю его подсистему) и быстрее его в 100 раз, и в 6 раз быстрее чисто по коду МТ5, да... и "решает" не только перебором и ГА но и порядка еще 50-тью вариантами. За сколько бы вы купили? За 1000$ купили бы? Почему так дорого - да просто покупателей то будите только Вы и еще десять человек. :)
Однако, я не представляю, как вы будете оптимизировать для унивесрального случая очень частую ситуацию:
Уже что-то представляю (но не до конца). Перед запуском оптимизатора надо произвести анализ на зависимость оптимизируемых входных параметров (в примере выше, две переменные независимы полностью). Далее оптимизацию проводить сначала по независимым переменным от наименьшего диапазона к наибольшему (не всегда так правильно, т.к. зависит еще от ресурсоемкости тех же индикаторов. Бывает, лучше 100 раз посчитать легкий индикатор, чем 5 раз тяжелый), кэшируя результаты.
Понятно, что реализация такой оптимизации очень сложная (особенно для облачного случая). Но если реализовать, то, как минимум, абсолютно все советники, созданные в MQL5 Wizard-е будут оптимизироваться на порядки быстрее. Потому что MQL5 Wizard - это комбинирование большого количества индикаторов между собой (т.е. там огромное количество независимых друг от друга входных параметров). Другое дело, что для профитной торговли такое занятие не имеет смысла...
Кеширование с последующей выборкой результатов на огромных (миллионы и десятки миллионов) выборках обходится дороже, чем непосредственный расчет.
Кеширование с последующей выборкой результатов на огромных (миллионы и десятки миллионов) выборках обходится дороже, чем непосредственный расчет.
Уверен, реализовать идеально универсальный оптимизатор так, чтобы он был настолько "смышленным", как описал выше практически нереально. Конечно, улучшать есть куда, но идеально сделать в любом случае не получится.
Огромные выборки (в десятки миллионов), конечно, это вы преувеличили значительно. Кэшировать подобное не надо совсем.
Думаю, вы все отлично понимаете, что имею в виду. И многие понимают. Никто даже критиковать за такое не будет, иначе это будет программистким невежеством критиканов. Потому что адекватные отлично понимают сложность реализации такого.
Насчет кэширования поясню все на том же примере:
Если индикатор не перерисовывается, то к концу очередного одиночного прогона в тестере у вас будет полный буфер всех значений индикатора. Он уже у вас есть. И если следующий проход использует все те же значения индикатора (вторая переменная не поменялась), то считать его заново не требуется. Вы можете из уже посчитанного буфера (который уже есть, кэшировать не надо, просто память с предыдущего прогона не полностью освободили) брать значения.
Если индикатор не перерисовывается, то
Уверен, реализовать идеально универсальный оптимизатор так, чтобы он был настолько "смышленным", как описал выше практически нереально. Конечно, улучшать есть куда, но идеально сделать в любом случае не получится.
Огромные выборки (в десятки миллионов), конечно, это вы преувеличили значительно. Кэшировать подобное не надо совсем.
Например, тест EURUSD за последние 11 лет дает больше 50 млн тиков.
Это означает, что для простого однобуферного индикатора типа MA придется сохранить 50 млн состояний (50 млн * 8 байт(double) = 400 мб буфер), что очень много. Если используется что-то посложнее или побольше количеством, то фактически кеш не влезет в память, не говоря уже об многоядерных агентах.
Мы прорабатывали идею кешей индикаторов и оказалось, что рассчитать очередное значение (да еще и с экономичным методом) индикатора гораздо быстрее и менее затратно по ресурсам, чем строить кеши.
Ага, именно по причине невозможности написать такой шустрый универсальный оптимизатор, неуниверсальные числодробилки всегда будут выигрывать по скорости. И в этом нет ничего ни плохого, ни хорошего.
Ничего они не выигрывают.
У них нет ни рыночного окружения, ни инфраструктуры, ни индикаторов, ни аналитики. А это главнее одноразового цикла (да еще и не представленного).
Например, тест EURUSD за последние 11 лет дает больше 50 млн тиков.
Мы же говорим об оптимизаторе, не как множество одиночных прогонов тестера. Концепция оптимизатора совсем в другом. Там существенный выигрышь в скорости достигается за счет незначительных погрешностей в результатах. Для оптимизатора совершенно не нужны модели по тикам. Максимум - по ценам открытия. Оптимизатор - это не много раз тестер, это другое совсем. У вас другой подход, тоже вполне логичный.
Ничего они не выигрывают.
У них нет ни рыночного окружения, ни инфраструктуры, ни индикаторов, ни аналитики. А это главнее одноразового цикла (да еще и не представленного).
Они выигрывают в скорости, потому что ничего быстрее почти лишь только цикла for не может быть. Иногда нужна именно скорость, и считалка уделает по скорости (но не по другим параметрам) любой универсальный тестер. Не только от MetaQuotes.
Доказать свое утверждение я не могу, по следующей причине:
Моя считалка - это просто реализация на C++ моего советника, где все операции специально сделаны целочисленным (цены - целые числа), где сведены полностью к нулю лишние проходы и т.д. Там нет ни интерфейса, ничего. Лишь на выходе файл с результатами оптимизации. Т.е. я могу на C++ написать советник с алгоритмической оптимизацией, и мой тестер не будет делать никаких торговых проверок (хватает ли маржи и т.д.). Не будет эмулировать историю и не будет считать индикаторы. В нем нет ничего универсального в плане универсальности MT5-тестера. Задача считалки лишь одна - быстро, максимально быстро считать. И она считает в сотню раз быстрее MT4-тестера, выдавая погрешность < 1%. Что тут показывать с моей стороны - вообще не понятно.
Вам же очевидно, что цикл for без проверок и с только целыми числами будет всегда считать быстрее универсального тестера.