Нужны ли dll библиотеки в Маркете для профессиональных торговых систем.
- [АРХИВ] Любой вопрос новичка, чтоб не захламлять форум. Профи, не проходите мимо. Без вас никуда - 3.
- Вопросы от "чайника"
- Как программно проверить - идет 'Оптимизация' или 'Форвард-оптимизация'?
Беда заключается в том, что функционала этого нет, и ждать, по всей видимости, не приходится.
Кроме того, с MQL и MT уже наверно 4 месяц колупаюсь. На выходе следующее:
1) почему-то разработчики не позаботились о нормальном импорте\экспорте результатов оптимизации. Да, можно сохранить в Ексель табличку "оптимизация" из тестера стратегий, и иии... все. Этого не происходит автоматически, не ведется учет версии стратегии (торгового робота), сравнивать что-то с чем-то очень затруднительно. А самое главное становится жутко обидно когда оптимизация проводилась 2 суток, потом вырубился комп (электричество отключилось) и все сначала... (хорошо не 2 недели). Результаты тестирования необходимо сохранять в файл во время выполнения, а не после всем копом. Необходимо также иметь возможность открыть этот файл и вывести отчет. Без этого логичного инструмента системный анализ результатов своей работы не возможен.
2) Неадекватно долгий процесс тестирования, который компенсируется платным сервисом Cloud Network. Я как-то прикинул стоимость тестирования через этот сервис и понял, что ежемесячно отчислять по 500-1000$ не очень хочется. Проще оказалось выгружать данные (историю, тики, и пр.) в файлы и обрабатывать (проводить тестирование и оптимизацию) без использования MQL.
3) Изобретение велосипедов, MQL очень беден библиотеками и взаимодействием с ОС приходится эти библиотеки делать самому. Другое дело IDE такие как Delphi, Visual Studio и другие которые имеют в себе массу инструментов.
Для этого необходимы адекватные инструменты для импорта\экспорта данных из MT, вот и интересуюсь нужны ли такие инструменты профессиональному сообществу или нет.
Ждем выпуска нового оптимизирующего компилятора MQL5 для x64 платформы для процессоров с SSE 4.2 - это в несколько раз повысит скорость математических вычислений, что позволит снизить потребность во внешних массивных вычислениях.
Для старых 32 битных MetaTrader 5 или процессоров без SSE 4.2 (в Атомах даже есть) будет использоваться текущий движок. В MetaTrader 4 изменений движка MQL4 не будет.
Связь со внешними системами уже сейчас доступна через WebRequest, SendFTP, SendMail, SendNotification и работу через пайпы. Возможно, в MQL5 включим прямой интерфейс в базы данных.
DLL в Маркете точно не будет, так как мы не собираемся подвергать опасности трейдеров. Количество вредителей достаточно велико и каждый день они так или иначе атакуют нашу экосистему со всех сторон.
Беда заключается в том, что функционала этого нет, и ждать, по всей видимости, не приходится.
Кроме того, с MQL и MT уже наверно 4 месяц колупаюсь. На выходе следующее:
1) почему-то разработчики не позаботились о нормальном импорте\экспорте результатов оптимизации. Да, можно сохранить в Ексель табличку "оптимизация" из тестера стратегий, и иии... все. Этого не происходит автоматически, не ведется учет версии стратегии (торгового робота), сравнивать что-то с чем-то очень затруднительно. А самое главное становится жутко обидно когда оптимизация проводилась 2 суток, потом вырубился комп (электричество отключилось) и все сначала... (хорошо не 2 недели). Результаты тестирования необходимо сохранять в файл во время выполнения, а не после всем копом. Необходимо также иметь возможность открыть этот файл и вывести отчет. Без этого логичного инструмента системный анализ результатов своей работы не возможен.
Позаботились.
Воспользуйтесь функцией OnTesterDeinit и генерируйте свои собственные отчеты по пройденному проходу. Довод про отключение электричества несерьезен.
Пункт никак не связан с включением DLL в магазине приложений.
2) Неадекватно долгий процесс тестирования, который компенсируется платным сервисом Cloud Network. Я как-то прикинул стоимость тестирования через этот сервис и понял, что ежемесячно отчислять по 500-1000$ не очень хочется. Проще оказалось выгружать данные (историю, тики, и пр.) в файлы и обрабатывать (проводить тестирование и оптимизацию) без использования MQL.
Процесс тестирования зависит от автора эксперта.
Если разработчик не применяет экономичных методов, то тестирование неминуемо будет долгим. Публичная расчетная сеть позволяет очень быстро получить результаты и такого решения нет ни у одной платформы. Как это умудрились записать в недостаток, я не понимаю. Особенно с учетом неограниченных возможностей по созданию своей собственной бесплатной расчетной фермы в локальной сети. Этого тоже ни у кого нет.
Если вы в состоянии выгружать тики и делать собственное тестирование, значит у вас заведомо достаточно компетенции написать экономичного эксперта, который будет эффективно и быстро работать в штатном тестере.
Этот пункт тоже никак не связан с включением DLL в магазине приложений.
3) Изобретение велосипедов, MQL очень беден библиотеками и взаимодействием с ОС приходится эти библиотеки делать самому. Другое дело IDE такие как Delphi, Visual Studio и другие которые имеют в себе массу инструментов.
Для этого необходимы адекватные инструменты для импорта\экспорта данных из MT, вот и интересуюсь нужны ли такие инструменты профессиональному сообществу или нет.
Если пишите для себя, то никаких проблем с использованием DLL нет.
Экспорт и импорт легко пишется на MQL4/MQL5 с любым уровнем детализации - все возможности есть.
Тут, конечно, нельзя не согласится, вредоносный код может внедрятся в DLL недобросовестными лицами.
Но вот тем не менее, остается ряд вопросов касательно тестера...
1) Возникает впечатление, что в каждом потоке (тут имеется ввиду работа одного агента) в каждом потоке все вычисления производятся по новой. Хотя необходимости в этом нет. Допустим проводится оптимизация по какому-то торговому инструменту за последние два года с использованием какого-то индикатора, у стратегии есть оптимизируемый параметр не влияющий на индикатор. Но судя по всему, он вычисляется каждый раз при прогоне.
2) Сдается мне, что больше всего процессорное время тратиться на генерацию трейдов и сделок. Чем больше сделок тем больше времени уходит на 1 прогон и это видно на глаз. Всякие проверки маржи в момент подачи сделки и т.д. и т.п. которые для проведения объективного анализа не нужны. Тут ИМХО ошибка проблема кроется в самом подходе: в MT эффективность измеряется в долларах, а на мой взгляд, должно измерятся в пунктах, ибо качество стратегии ни как не зависит от размера капитала. По результатам тестов можно судить о необходимом объеме денежных средств для той или иной стратегии.
Что касается связи с СУБД, мне эта задача не кажется критичной. Базы данных нужны, если требуется доступ в разные сегменты данных. При прогонах, тестах и оптимизации данные нужны последовательно 1 тик 2 тик... поэтому чтение бинарного файла вполне сгодится. Кроме того тут маленькое исследование провел: два года истории по EURUSD генерирует примерно 34 500 000 тиков. Допустим существует некий индикатор с 5 буферами. Что это означает? Из истории нужно: Время, БИД, АСК, Объем, + 5 буферов для воображаемого индикатора, сколько памяти по это потребуется? 8байт * 9 * 34500000 = ~2.5-3гб. Эти данные можно свободно пихнуть в ОЗУ и работать с ними. По этому СУБД только жизнь осложнит.
В тоже время, повторюсь, нет нормальной возможности сохранения промежуточных результатов оптимизации, продолжения оптимизации после какого-либо сбоя, результаты оптимизации содержат только информацию о входных параметрах и размер прибыли\убытка, чтобы получить информацию о сделках, ордерах и вывести отчет нужно !!помнить период тестирования, торговый инструмент, таймфрем!! настроить все, запустить и ждать пока прогон все скалькулирует, а это бывает очень долго. И так для каждого результата. И тут понимаешь, что старость не за горами.
Тут, конечно, нельзя не согласится, вредоносный код может внедрятся в DLL недобросовестными лицами.
Но вот тем не менее, остается ряд вопросов касательно тестера...
1) Возникает впечатление, что в каждом потоке (тут имеется ввиду работа одного агента) в каждом потоке все вычисления производятся по новой. Хотя необходимости в этом нет. Допустим проводится оптимизация по какому-то торговому инструменту за последние два года с использованием какого-то индикатора, у стратегии есть оптимизируемый параметр не влияющий на индикатор. Но судя по всему, он вычисляется каждый раз при прогоне.
Что вы подразумеваете под "все вычисления"? Да, индикаторы постоянно считаются, если их явно активировал эксперт.
Чтобы оценить объемы данных для потенциального кеширования (например, закешировать состояние индикатора на каждом тике), посмотрите на итоговое количество сгенерированных тиков. Учтите, что почти всегда вычислить индикатор заново дешевле, чем сохранить/поднять из кеша(особенно дискового).
2) Сдается мне, что больше всего процессорное время тратиться на генерацию трейдов и сделок. Чем больше сделок тем больше времени уходит на 1 прогон и это видно на глаз. Всякие проверки маржи в момент подачи сделки и т.д. и т.п. которые для проведения объективного анализа не нужны. Тут ИМХО ошибка проблема кроется в самом подходе: в MT эффективность измеряется в долларах, а на мой взгляд, должно измерятся в пунктах, ибо качество стратегии ни как не зависит от размера капитала. По результатам тестов можно судить о необходимом объеме денежных средств для той или иной стратегии.
Чтобы оценить и понять процессы, протекающие в тестере, надо самому пару тестеров стратегий написать. И как минимум, прочитать ряд статей про тестер на этом сайте.
Включите мультивалютного эксперта и запустите режим визуализации, пожалуйста. Посмотрите что и как моделируется параллельно. Ну а "быстрый побарный тестер пипсов" - это настолько отсталый подход, что даже вспоминать не хочется. Первый примитивный тестер на MQL мы выпустили еще в 2001 году, 14 лет назад. С тех пор функциональность тестеров у нас многократно выросла.
Что касается связи с СУБД, мне эта задача не кажется критичной. Базы данных нужны, если требуется доступ в разные сегменты данных. При прогонах, тестах и оптимизации данные нужны последовательно 1 тик 2 тик... поэтому чтение бинарного файла вполне сгодится. Кроме того тут маленькое исследование провел: два года истории по EURUSD генерирует примерно 34 500 000 тиков. Допустим существует некий индикатор с 5 буферами. Что это означает? Из истории нужно: Время, БИД, АСК, Объем, + 5 буферов для воображаемого индикатора, сколько памяти по это потребуется? 8байт * 9 * 34500000 = ~2.5-3гб. Эти данные можно свободно пихнуть в ОЗУ и работать с ними. По этому СУБД только жизнь осложнит.
В тоже время, повторюсь, нет нормальной возможности сохранения промежуточных результатов оптимизации, продолжения оптимизации после какого-либо сбоя, результаты оптимизации содержат только информацию о входных параметрах и размер прибыли\убытка, чтобы получить информацию о сделках, ордерах и вывести отчет нужно !!помнить период тестирования, торговый инструмент, таймфрем!! настроить все, запустить и ждать пока прогон все скалькулирует, а это бывает очень долго. И так для каждого результата. И тут понимаешь, что старость не за горами.
Вы не в курсе, что тестирование можно остановить и продолжить? Это работает автоматически в виде создания кешей промежуточных результатов. Если условия не поменялись, то будут использованы предыдущие результаты. Но это именно, если условия не изменились.
В любом случае, эти жалобы беспочвенны. Никто на себя не будет брать ответственность за возможность неограниченного изменения рыночного окружения между остановкой и запуском повторных вычислений.
Вот этот пункт не понял "Нужны программы вывода тиков, BID ASK в файлы, для дальнейшей обратотки". Это делается за 15 мин. на коленке, при чем тут маркет вообще? ДЛЛ вообще нужны, но в маркете опасны. Одно дело, когда я заказчику сразу говорю, что буду использовать готовую ДЛЛ для парсинга, к примеру. И он меня знает и доверяет. А маркет - это как массовая продажа колбасы в магазине, должна быть гарантия качества, независимо от поставщика.
А в целом, чего не хватает в MQL4/5 - хотя бы аналога STL. Имеем начальный набор классов-контейнеров и все. Могу предложить MQ, по аналогии с платным написанием статей, привлечь программистов с этого сайта для разработки такой библиотеки. Только не фрилансеров за $20, а грамотных людей.
Могу предложить MQ, по аналогии с платным написанием статей, привлечь программистов с этого сайта для разработки такой библиотеки. Только не фрилансеров за $20, а грамотных людей.
Ой не, лучше штатным поручить. Здешних кодеров нормальных по пальцам пересчитать
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования