Обсуждение статьи "Пользовательский тестер стратегий на основе быстрых математических вычислений" - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы не поняли меня. Вы предлагаете ТС для теста писать на своем торговом API специально для этого. А это равносильно использованию других тестерных решений.
Ну и пункт с кастомными символами проигнорили, как и сравнение скоростей в цифрах.
Не все сразу. Сравнение по скорости обязательно будет в другой части.
Через шаблоны. В КБ такое выкладывал.
Соответственно, если FrameNext хоть в одном из OnTesterPass не вызвать, то все последующие OnTesterPass+FrameNext будут получать не пришедший проход, а предыдущий.
Поскольку статья обучающая, то данный нюанс не помешало бы реализовать в коде в виде тех же комментариев.
И без шаблонов очень универсальный union получился. Нет, шаблонов не будет точно. Не мой стиль просто.
У Вас почти половина кода занимают байтовые операции. И они сильно зависят от задач. По-моему, можно написать гораздо универсальнее и лаконичнее. Но хозяин - барин.
Вы не поняли меня. Вы предлагаете ТС для теста писать на своем торговом API специально для этого. А это равносильно использованию других тестерных решений.
Vasiliy Sokolov:
Теоретически возможно использовать единое API. Единственное абстрактное API, которое сейчас имеется это CStrategy. Вот его поддержку и можно реализовать в математическом тестере.
Тогда это будет решение только для Вас. Если реализовать, то либо MQ4/5, либо СБ на крайний случай.
Но даже если реализовывать поддержку базовых вещей - это очень сложная задача. Поэтому таки-да, сейчас да и в обозримом будущем API разное, следовательно и ТС придется писать дважды.
Это и фигово. Писать ТС на одном API, затем переписывать на другой и искать, а где же расхождения.
Однако сравнивать со сторонними тестерами не совсем корректно, потому что все-таки все расчеты происходят в инфраструктуре MetaTrader и блок анализа един. Т.е. всегда можно прогнать ТС в стандартном тестере и даже на демке и сравнить отчет с таковым в мат. тестере. Может быть в следующей части интегрирую отчетность с стандартным тестером МТ.
Инфраструктура MT здесь - это Агенты и GUI задания параметров. В общем, сомнительно.
Тестер MT тем и крут, что большинство боевых советниклв можно без изменений проверить на виртуальном торговом окружении.
Грандиозная работа проделана! Мои замечания ниже.
Режим мат. вычислений не подходит для решения поставленной задачи по нескольким причинам.
В самой статье, сразу после перечисления его преимуществ, в том числе — отсутствия подготовки данных тайм-серий, начинается собственная реализация того же функционала! :)
В виду отсутствия сравнения скорости полученного велосипеда со встроенным режимом "По ценам открытия", становится вообще не понятным, есть ли хоть какой-то выигрыш хотя бы для такой примитивной стратегии.
О вопросах еще одного торгового API высказался fxsaber, полностью с ним согласен. Решение должно быть универсальным, иначе рискует быть даже не невостребованным, а не опробованным. Ну, а необходимость переписывания индикаторов (в том числе, стандартных) для простой проверки идеи, ставит на этом подходе жирный крест.
В "планах на будущее" озвучено дальнейшее движение к стандартным "Ценам открытия", поэтому совсем не понятно, какая ценность у этого тестера, кроме демонстрационно-обучающей.
Тема фреймов и управления оптимизацией куда более интересна и заслуживает более подробной проработки и обертки в удобные универсальные функции.
Также интересен Анализатор, как альтернатива штатным отчетам и штатному процессу оптимизации вообще (имею в виду пост-обработку всех проходов благодаря наличию собственного кэша).
Именно в этом направлении, на мой взгляд, стоит продолжать цикл статей.
Спасибо за работу!
Хотя Рождество прошло давно, я бы хотел, чтобы ваш тестер стратегий мог читать и обрабатывать данные локального тика в формате ASCII.
Данные по тику выросли до ~ 400 ГБ на внешнем USB-HD с помощью бесплатного TickDownloader со мной - который я бы хотел использовать - другие, вероятно, также - чтобы не зависели от разных брокеры. Возможно также с возможностью одновременного использования нескольких символов (арбитраж, корзины, ...).
Это также было бы интересно для MT4, потому что он не может этого сделать!
Although Christmas is long gone, I would wish that your strategy tester could read and process the local tick data in ASCII format.
The tick data has grown to ~400 GB on an external USB-HD by the free https://strategyquant.com/tickdownloader# with me - which I would like to use - others probably also - in order not to be dependent on different brokers. Possibly also with the possibility to use several symbols at the same time (arbitrage, baskets,...).
That would also be interesting for the MT4, because it can't do that!
(by google translate)
Calli
PA: Anyway thanks for this interesting approach!
Спасибо за интересную статью.
Считаю, что тестеру необходимы стандартные торговые функции - открытие/закрытие/TP/SL, которые можно было бы легко добавить в любой советник и получить приблизительный результат без сверх усилий.
Относительно индикаторов, тут опять же необходимо реализовать возможность загрузки показателей индикаторов из файла/файлов, и сделать это так, что бы у агентов оставался этот файл, а не передавался постоянно (если этого нет). Соответственно реализовать при инициализации подмен хендла с индикатора на массив файла с готовыми расчетами индикатора. И, если большое число таких массивов будет работать достаточно быстро, то в этом действительно есть прок.
Сам режим "Математические вычисления" следует, видимо, рассматривать как урезанный аналог скрипта, который нужен для каких либо вычислений не связанных с индикаторами.
Уважаемый Василий, скажите пожалуйста, а есть ли механизм создания обратной связи советников при оптимизации, когда по результатам анализа оптимизации можно продолжить оптимизацию по иным критериям без ручного вмешательства? Какой то аналог ГА в плане управления параметрами оптимизации.
При компиляции файла ZipHeader.mqh в последний версии ругается одинаково в трех местах
1. 1. Строка -53 Столбец- 23 'ZipLocalHeaderOpen' has constructor and cannot be used as union member
2. 2. Строка -142 Столбец- 28 'ZipCentralDirectoryOpen' has constructor and cannot be used as union member
3. 3. Строка -221 Столбец- 21 'ZipEndRecordOpen' has constructor and cannot be used as union member
Возможно ужесточились требования компилятора. Подскажите как правильно подправить код.