Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Редкий случай, значит можно руками сбросить кеши либо написать специальную библиотеку для зачистки.
А это как?
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Пиши и зарабатывай на MQL5
fxsaber, 2017.09.07 07:47
На статью не тянетно как подпункт статьи
хранение и передача любых данных через глобальные переменные и ресурсы.
"Хранение и передача данных без использования DLL - все варианты".
А это как?
Открываем папку тестера и зачищаем файлы в кеше
Открываем папку тестера и зачищаем файлы в кеше
что-то я тупанул по утру, думал что-то новое ввели ) спасибо
Редкий случай, значит можно руками сбросить кеши либо написать специальную библиотеку для зачистки.
Бывают ситуации, когда это нужно почти всегда. И можно делать без DLL, а значит годится для того же Маркета.
А как чистить кэш оптимизации не вручную и без DLL?
P.S. Какой-то баг в сайте - не появляются линки "В карман", "Жалоба", "Ответить" для некоторых сообщений.
А как чистить кэш оптимизации не вручную и без DLL?
Никак! Речь шла о другом - обход кеша. Делаю это так
Никак! Речь шла о другом - обход кеша. Делаю это так
Не врубаюсь - зачем генерить несколько входных значений? Ведь одного случайного по идее достаточно, чтобы набор считался другим, т.е. не брался из кеша.
Правда, кэш в любом случае при этом будет раздуваться.
Еще вдруг возник вопрос: зачем в функции ParameterSetRange через 3-й параметр передается "текущее" значение? Ведь функция - только для оптимизации, а во время оптимизации значения будут меняться от start до stop с шагом step.
Не врубаюсь - зачем генерить несколько входных значений? Ведь одного случайного по идее достаточно, чтобы набор считался другим, т.е. не брался из кеша.
Код выдран из библы, на которую ссылка ниже. Отсюда и причина набора значений.
Правда, кэш в любом случае при этом будет раздуваться.
Так это ни на чем не сказывается.
Еще вдруг возник вопрос: зачем в функции ParameterSetRange через 3-й параметр передается "текущее" значение? Ведь функция - только для оптимизации, а во время оптимизации значения будут меняться от start до stop с шагом step.
Там второй параметр true, поэтому без разницы, что указывать в третьем.
Но если юзер, который использует библу, захочет во фрейм-режиме посмотреть, чему равны входные параметры его советника, то он увидит через ParameterGetRange, чему равно количество проходов, а не число от балды. Поэтому третий параметр прописывается на такой случай.
Никак! Речь шла о другом - обход кеша. Делаю это так
Действительно, на статью не тянет, но стало интересно - в каких случаях необходим такой трюк? Я имею в виду именно ситуацию, когда нужно заставить тестер не принимать в расчет готовые проходы из кеша предыдущей оптимизации при неизменном наборе влияющих входных параметров.