Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
OPT файлы вроде есть после одиночной оптимизации
Если заменить символ или интервал тестирования, то новый opt-файл не появится, а будет перезаписан старый.
Правильно, когда изменение входных данных создает соответствующий opt-файл.
Ну и если загрузили opt-файл в Тестер, то из него хорошо бы иметь возможность запускать сразу одиночные проходы.
Разница, как здесь.
Но все же причина, скорее всего, не в сжатии тиков. Вы не тратите ресурсы на проброс тика в виртуалку и получение его оттуда через SymbolInfoTick. Грубо говоря, вы не делаете на каждом тике два присваивания MqlTick и проверку работы с ордерами (хоть их и ноль).
Добавил сжатие тиковых данных. 2 уровня:
1) закодировал сжатие через дельты цен и времени.
2) дополнительно можно применить сжатие ZIP. Вариант с полными тиками в 1,5 раза компактнее чем сумма .tcs за тот же год, а AskBid в 3,5 раза.
Вариант AskBid стал сравним с вашим по скорости. Так что сжатие тиков добавило времени.
Добавил сжатие тиковых данных.
Вариант AskBid стал сравним с вашим по скорости.
Взял этот скрипт, чтобы минимальными усилиями встроить предложенный метод сжатия для проверки его корректности.
Не смог разобраться, почему не сжимается, а на разжатии вылет за пределы массива.
Вот думаю, что если так компактно получилось - то можно сохранить всю историю за 5-6 лет и через инпуты указывать интервал тестирования. Ну и дать имена в виде названий инструментов. Подумаю...
Вариант AskBid стал сравним с вашим по скорости. Так что сжатие тиков добавило времени.
Взял этот скрипт, чтобы минимальными усилиями встроить предложенный метод сжатия для проверки его корректности.
Не смог разобраться, почему не сжимается, а на разжатии вылет за пределы массива.
У меня используется статический массив
MqlTick Ticks[1000];
При заполнении сжимается этот блок, потом следующие 1000 и т.д. В конце остаток <1000 сжимает.
У меня используется статический массив
MqlTick Ticks[1000];
При заполнении сжимается этот блок, потом следующие 1000 и т.д. В конце остаток <1000 сжимает.
Могли бы сделать этот исходник рабочим? Без него невозможно понять корректность алгоритма сжатия/разжатия и его характеристики.
Читал исходник, конечно.
Могли бы сделать этот исходник рабочим? Без него невозможно понять корректность алгоритма сжатия/разжатия и его характеристики.
Взял этот скрипт, чтобы минимальными усилиями встроить предложенный метод сжатия для проверки его корректности.
Переделал код для более быстрой работы с большими массивами. Ранее использовался статический массив для 1000 тиков. Сделал динамическим, и чтение с любого места, а не с 0. Аналогично при сохранении распакованных тиков сделал запись тиков в любое место массива.
Для работы с сохранением тиков в файл все это не нужно, запись и чтение данных по прежнему идет блоками от 0 позиции в массиве. Большие массивы не использую, т.к. если в него поместить тики за несколько лет, то это может занять несколько Гб памяти + память потребляется экспертом, а при оптимизации на каждый агент не видел более 2Гб, видимо лишнее скидывается в кэш на диске. + Ресайз массивов медленная операция. И еще одна причина - то, что ZIP архивация работает с данными не более 1,5Гб, если больше - то будут сбои.
Но для вашего теста сделал эти изменения.
Кстати, ранее размер блоков перебирал до 1000. С вашим скриптом перебирал до 2млн. Оказалось, что быстрее всего с вашим скриптом распаковка идет при int ticks_per_block=600000;.
А себе для работы с файлами подобрал 30 000 вместо 1000.
Проверьте разные
для Ask и Bid 1 и 4 варианты. 4й с ZIP.
Сбор тиков в большой массив (для сравнения с исходными тиками) перенес из цикла для оценки производительности в отдельный, из за описаных выше причин. Работать с тиками можно из малых блоков без предварительной склейки их в один массив.