Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
всего 290 и... дальше)
Полный перебор делает 290.
Я так понимаю, что прохода(реального прогона) нет но он фиксируется(если есть совпадения)?
Так как Вы выбрали генетический алгоритм, то он сам строит свой план скрещивания и вывода популяций. Алгоритм работы генетического оптимизатора описан в соответствующей статье.
Неразумно при столь малом количестве (290) проходов запускать генетику. Генетический алгоритм нужно использовать при исходном переборе как минимум десятков тысяч, а лучше миллионов/миллиардов/триллионов вариантов.
Опечатка в Справочник MQL5 - Стандартная библиотека - Классы для организации данных - CArrayObj (на сайте и в хелпе):
2. Механизм управления памятью выключен.
В этом случае, CArrayObj не ответствечает за освобождение памяти
Да, не нужно проводить тестирование до самой последней существующей даты.
Выберите разумную фиксированную конечную дату в виде 00:00 предыдущего рабочего дня или даже конец прошлой рабочей недели. Если постоянно использовать последний день, то конец графика будет периодически плавать, особенно если процесс тестирования долгий с использованием удаленных или клауд агентов.
В качестве конечной даты использовал воскресенье. Куда еще разумнее? Торгов в воскресенье нет. Что там может плавать???
Тогда, возможно, проблема на другом конце истории. Какая длина истории вам нужна для работы индикаторов? В начале тестирования гарантируется, как я понял, сотня предшествующих баров.
Если нужно больше, пропускайте кусок истории после старта эксперта, на длину превышающую [необходимое_число_баров - 100]. У меня это решило проблемы с соответствием результатов тестера и оптимизатора.
Тогда, возможно, проблема на другом конце истории. Какая длина истории вам нужна для работы индикаторов? В начале тестирования гарантируется, как я понял, сотня предшествующих баров.
Если нужно больше, пропускайте кусок истории после старта эксперта, на длину превышающую [необходимое_число_баров - 100]. У меня это решило проблемы с соответствием результатов тестера и оптимизатора.
Спасибо, но по скринам видно, что при оптимизации через сеть потерялась история за пятницу (24.06.11)
Не принципиальный вопрос, но все же. Конкатенация строк. В документации описаны две функции StringAdd и StringConcatenate.
В первой указано: "Функция StringAdd() работает быстрее и экономнее по памяти, чем связывание строк при помощи операций сложения".
Во второй: "Функция StringConcatenate() работает быстрее и экономнее по памяти, чем связывание строк при помощи операций сложения за счет того, что не используются временные переменные типа string".
Результат:
2011.06.26 19:10:55 test (EURUSD,H1) №1 2012 milliseconds, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1) №2 8269 milliseconds, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1) №3 6661 milliseconds, i = 10000000
Выходит, все же, обычное сложение быстрее.
Выходит, все же, обычное сложение быстрее.
В качестве конечной даты использовал воскресенье. Куда еще разумнее? Торгов в воскресенье нет. Что там может плавать???
Так как такого рода вопросы требуют деталей, создайте тикет в сервисдеске с указанием дополнительных описаний - попробуем разобраться.
Проблема конечно же в истории и ее синхронизированности.
Не принципиальный вопрос, но все же. Конкатенация строк. В документации описаны две функции StringAdd и StringConcatenate.
В первой указано: "Функция StringAdd() работает быстрее и экономнее по памяти, чем связывание строк при помощи операций сложения".
Во второй: "Функция StringConcatenate() работает быстрее и экономнее по памяти, чем связывание строк при помощи операций сложения за счет того, что не используются временные переменные типа string".
Результат:
2011.06.26 19:10:55 test (EURUSD,H1) №1 2012 milliseconds, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1) №2 8269 milliseconds, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1) №3 6661 milliseconds, i = 10000000
Выходит, все же, обычное сложение быстрее.
Похоже, что это срабатывает оптимизация конкатенации строк через +.
У нас сейчас серьезно изменяется компилятор в плане включения давно ожидаемых режимов оптимизации. Через некоторое время будем показывать результаты.
Похоже, что это срабатывает оптимизация конкатенации строк через +.
У нас сейчас серьезно изменяется компилятор в плане включения давно ожидаемых режимов оптимизации. Через некоторое время будем показывать результаты.
Ясно. Ну, если можно вы об этом явно опишите на форуме (стараюсь следить за всеми ветками).
Пока в алгоритме оставил работу "+".