Новая статья: Структура данных в MetaTrader 4 build 600 и выше - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Перед каждым одиночным прогоном ранее сгенерированный тиковый файл стирается автоматически
Доброе утро, Слава! Извините, я позже встаю по европейскому времени и только что прочитал ваши ответы! Спасибо!
Но, к сожалению, действительно, только удаляя оба файла (тиковый и сache) в тестере достигается эффект от оптимизации на том участке, на котором хоть раз прогонял!
Если каждый раз не удалять, даже проверяя другой параметр, тестер выдаёт ту же "прекрасную маркизу"! Простите за сравнение, но только благодаря помощи evillive смог добиться нормального функционирования тестера. Но согласитесь, что это очень обременительно перед каждым прогоном или оптимизацией теперь нужно стирать эти файлы. Раньше я не знал этого. И эти файлы сами не стираются и аккумулируют этих ненужных данных до несколько МВ!
Пожалуйста, сделать возможность удалять эти файлы нажатием кнопки или предусмотреть выбор отключения создания этих файлов! Премного был бы благодарен и не только я!
Доброе утро, Слава! Извините, я позже встаю по европейскому времени и только что прочитал ваши ответы! Спасибо!
Но, к сожалению, действительно, только удаляя оба файла в тестере достигается эффект от оптимизации на том участке, на котором хоть раз прогонял!
Если каждый раз не удалять, даже проверяя другой параметр, тестер выдаёт ту же "прекрасную маркизу"! Простите за сравнение, но только благодаря помощи evillive смог добиться нормального функционирования тестера. Но согласитесь, что это очень обременительно перед каждым прогоном или оптимизацией теперь нужно стирать эти файлы. Раньше я не знал этого. И эти файлы сами не стираются и аккумулируют этих ненужных данных до несколько МВ!
Пожалуйста, сделать возможность удалять эти файлы нажатием кнопки или предусмотреть выбор отключения создания этих файлов! Премного был бы благодарен и не только я!
"Борис, ты не прав." (ц)
Если всё как ты говоришь, значит просто есть какой-то баг в реализации алгоритма. Его надо найти и поправить. А не отказываться от алгоритма.
Лучче сооруди воспроизводимый пример и скинь в сервисдеск.
"Борис, ты не прав." (ц)
Если всё как ты говоришь, значит просто есть какой-то баг в реализации алгоритма. Его надо найти и поправить. А не отказываться от алгоритма.
Лучче сооруди воспроизводимый пример и скинь в сервисдеск.
Я не в состоянии это сделать, т.к. я не специалист информатики, ни офиматики, и не проф. программист, а скромный пользователь! И не любитель что-то выдумывать! Эти одинаковые результаты при оптимизации, если не удалять эти файлы, как раз говорят о том, что тестер мне выдаёт уже записанное в файлах, о чём предупреждают в журнале! Чем чревато это? Чувствительная расплата на Реале!
Я не в состоянии это сделать, т.к. я не специалист информатики, ни офиматики, и не проф. программист, а скромный пользователь! И не любитель что-то выдумывать! Эти одинаковые результаты при оптимизации, если не удалять эти файлы, как раз говорят о том, что тестер мне выдаёт уже записанное в файлах, о чём предупреждают в журнале! Чем чревато это?
Если всё работает правильно, это чревато только экономией времени на оптимизацию.
Давай разберёмся. Допустим у меня три int параметра (к примеру Х, Y, Z). Я провожу две оптимизации. Допустим в первой я задал диапазон изменений первых двух параметров от -50 до +50, с шагом 2, параметр Z фиксирован (напр = 0). Провёл оптимизацию, получил результаты. Затем я решил оптимизировать сразу по всем трём параметрам, и к тому же уменьшил шаг оптимизации (= 1) у первых двух параметров, а Z у меня изменяется в диапазоне от -1 до +1 с шагом 1. Тогда каждый раз, когда в процессе второй оптимизации нужно протестировать набор параметров в котором X и Y чётные а Z = 0, результат прогона можно не расчитывать, а брать из кеша в готовом виде, поскольку он уже был расчитан в процессе первой оптимизации. В данном примере экономия времени была бы около 8% (= 1/12, если точнее ). Собсно при правильной работе всё должно происходить именно так.
Чувствительная расплата на Реале!
Только если что-то работает неправильно! Пока непонятно, возможно ты пугаешься теней.
Как говорит Ренат "Какие будут ваши доказательства, сударь?" :)
Я в сервисдеск написал раньше насчёт автоматической очистки истории тестера после окончания теста, иногда там до нескольких гигов мусора скапливается, но ответа пока нет, надо больше заявок наверное на эту тему...
Научите меня как сделать эту заявку, я других тоже научу, тут много таких как я, не разбирающихся в этих дебрях!
Я в сервисдеск написал раньше насчёт автоматической очистки истории тестера после окончания теста, иногда там до нескольких гигов мусора скапливается, но ответа пока нет, надо больше заявок наверное на эту тему...
Сразу после окончания теста можно очищать.
Сразу после окончания оптимизации - нельзя. Так как может понадобиться ещё оптимизация на этих же исторических данных
А вообще, можно чистить кешированные тестерные данные через, скажем, 5 дней после последнего использования
Но, к сожалению, действительно, только удаляя оба файла (тиковый и сache) в тестере достигается эффект от оптимизации на том участке, на котором хоть раз прогонял!
Если каждый раз не удалять, даже проверяя другой параметр, тестер выдаёт ту же "прекрасную маркизу"! Простите за сравнение, но только благодаря помощи evillive смог добиться нормального функционирования тестера. Но согласитесь, что это очень обременительно перед каждым прогоном или оптимизацией теперь нужно стирать эти файлы.
Сразу после окончания теста можно очищать.
Сразу после окончания оптимизации - нельзя. Так как может понадобиться ещё оптимизация на этих же исторических данных
А вообще, можно чистить кешированные тестерные данные через, скажем, 5 дней после последнего использования