Ошибки, баги, вопросы - страница 212
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да, именно так, только в виде стандартных функций, чтоб была оптимизирована скорость доступа.
ну я думаю, что про скорость можно пока не говорить. тем более что имеющийся массив данных новостей MQL5 обрабатывает быстро. четырехлетняя история всех новостей за полсекунды. И это с надеждой, что MQL будет еще быстрее.
вот только я бы хотел развить тему. Мне интересно что потом планируется делать с этими данными? конкретные примеры использования?
ну я думаю, что про скорость можно пока не говорить. тем более что имеющийся массив данных новостей MQL5 обрабатывает быстро. четырехлетняя история всех новостей за полсекунды. И это с надеждой, что MQL будет еще быстрее.
вот только я бы хотел развить тему. Мне интересно что потом планируется делать с этими данными? конкретные примеры использования?
А дальше непаханая целина, новостей штатно раньше небыло, дальше начнётся бум кодирования новостных стратегий.
ЗЫ Я например планирую всё это пользовать через комитеты НС.
ЗЗЫ Но пока новостей в тестере не появится (то бишь истории новостей) это всё придётся делать через файлы,и парсер новостей на сторонних ресурсах.
Тестер тормозит при увеличении числа сделок.
При открытии сделок с интенсивностью примерно 1 сделка за 2 минуты видно (вкладка журнал), что на 1 секунду времени тестирования к концу достаточно длительного периода приходится в несколько раз меньше сделок, чем в начале теста. Схожая картина при выводе результатов тестирования в формат Open XML.
На самом деле время тестирования не напрямую зависит от количества сделок. Точнее, одиночный прогон с 10 сделками конечно займет времени меньше, чем прогон с 100 000 сделок, так как каждая сделка в тестере требует времени на обработку.
Но больше всего на время тестирования влияет количество тиков, которые обрабатываются в проходе. Я прогнал стандартный Moving Average в режиме все тики начиная с одного месяца (интервал 2009.01.01-2009.02.01) и каждый раз увеличивая время тестирования на один месяц завершил на 22 месяцах.
Как видно из построенной диаграммы, зависимость времени тестирования от количества тиков строго линейная.
Здравствуйте, отразите добавление конструкции
#property tester_indicator "индикатор.ex5"
в документации, в описании функции iCustom. Иначе к такой конструкции самостоятельно прийти нельзя, потратил несколько часов пытаясь понять в чем дело - почему iCustom работает на графике, но не работает в тестере.
Об этом сказано в разделе Свойства программ.
tester_indicator
string
Имя пользовательского индикатора в формате "имя_индикатора.ex5". Необходимые для тестирования индикаторы определяются автоматически из вызова функций iCustom(), если соответствующий параметр задан константной строкой. Для остальных случаев (использование функции IndicatorCreate() или использование неконстантной строки в параметре, задающем имя индикатора) необходимо данное свойство
tester_file
string
Имя файла для тестера с указанием расширения, заключенное в двойные кавычки (как константная строка). Указанный файл будет передан тестеру в работу. Входные файлы для тестирования, если необходимы, должны указываться всегда
tester_library
string
Имя библиотеки с расширением, заключенное в двойные кавычки. Библиотека может быть как с расширением dll, так и с расширением ex5. Необходимые для тестирования библиотеки определяются автоматически. Однако, если какая-либо библиотека используется пользовательским индикатором, то необходимо использовать данное свойство
Но Вы правы, необходимо еще раз явно добавить информацию об этом в соответствующих местах.
На самом деле время тестирования не напрямую зависит от количества сделок. Точнее, одиночный прогон с 10 сделками конечно займет времени меньше, чем прогон с 100 000 сделок, так как каждая сделка в тестере требует времени на обработку.
Но больше всего на время тестирования влияет количество тиков, которые обрабатываются в проходе. Я прогнал стандартный Moving Average в режиме все тики начиная с одного месяца (интервал 2009.01.01-2009.02.01) и каждый раз увеличивая время тестирования на один месяц завершил на 22 месяцах.
Как видно из построенной диаграммы, зависимость времени тестирования от количества тиков строго линейная.
Вероятно, следует читать "одиночный прогон с 10 сделками конечно займет времени МЕНЬШЕ, чем прогон с 100 000 сделок, так как каждая сделка в тестере требует времени на обработку.
Про тики согласен. Но прошу ещё раз обратить внимание именно на число сделок - там рост времени явно не линейный, а уж формирование отчёта о тестировании вообще ни в какие ворота не лезет!
какое максимальное время можно ставить в EventSetTimer( )?
INT_MAX? По моему нет. Не хочу исследовать самостоятельно, а в хелпе нет.
Вероятно, следует читать "одиночный прогон с 10 сделками конечно займет времени МЕНЬШЕ, чем прогон с 100 000 сделок, так как каждая сделка в тестере требует времени на обработку.
Про тики согласен. Но прошу ещё раз обратить внимание именно на число сделок - там рост времени явно не линейный, а уж формирование отчёта о тестировании вообще ни в какие ворота не лезет!
в процессе тестирования возникло несколько вопросов, показываю картинки сделанные одновременно:
как видно из рисунка, работают только три ядра, сталкивался не раз с ситуацией, когда в процессе тестирования количество ядер участвующих в работе постепенно падало до нуля, после чего вступали в работу все разом, т.е. есть простой в работе, почему освободившиеся ядра не начинают работу сразу?
количество прогонов определено как 287, в результатах оптимизации так оно и видно, однако:
что означают тогда эти цифры? Количество точек на графике оптимизации тоже примерно 381...