obla4ko:а по поводу тестирования на истории вопрос :
может ли советник (простенький!:)) - не сетка) на одной и том же отрезке истории,с одними и теми же параметрами давать совершенно различные результаты?
Единственное что, я, между этими двумя тестированиями, обновила архив котировок... и это могло привести к такому результату!? - тогда получается, что вся история - это фигня!?
1. История может изменятся. Фильтруются внутридневные гэпы, убираются выбросы и пр. Иногда даже дни пропадают! // Кто-то жаловался тут недавно, что месяц украли. Не ДЦ, а прям какой-то черт из "Вечеров на хуторе близ Диканьки"! )))
2. Разница может быть также из-за плавающего спреда. Тестер использует текущий на момент запуска.
3. История - не фигня. Фигня - это советник, который так зависит от таких мелочей.
также, по-моему, возможна "шпилька", в дальнейшем подчищенная..:)), но "сохраненная в памяти" более мелких таймфреймов, до которых уже не добраться...
а по поводу тестирования на истории вопрос :
может ли советник (простенький!:)) - не сетка) на одной и том же отрезке истории,с одними и теми же параметрами давать совершенно различные результаты?
Единственное что, я, между этими двумя тестированиями, обновила архив котировок... и это могло привести к такому результату!? - тогда получается, что вся история - это фигня!?
Точно... сами только что писали о подтирании "шпилек". Плюс ещё при тестировании спред берётся текущий. А он может и различаться: на прошлом тесте он был 2 пункта, а на текущем стал 4, например...
Спасибо за разъяснение - а как Вы считаете, нельзя ли вместо сравнения со значением Time[0] попробовать дать такое задание перед запросом OrderSend(...) : проверить, есть ли на текущем баре закрытие по StopLoss-y? Тогда нужно вводить функцию duble StopLoss(), которая будет работать с объявленной мною переменной StopLoss? Или это все-таки принципиально НЕ ВОЗМОЖНО? Мне важно, чтобы на баре, на котором поймали лося, новая позиция не открывалась, даже если по параметрам он подходит под открытие.
Дело в том, что ко временнЫм факторам хотелось бы обратиться в последнюю очередь - очень часто проскальзывают - вернее интерпретация приказа почему-то получается разнородной (неоднозначной)
artmedia70: Точно... сами только что писали о подтирании "шпилек". Плюс ещё при тестировании спред берётся текущий. А он может и различаться: на прошлом тесте он был 2 пункта, а на текущем стал 4, например...
точно, похоже програмки надо писать, толщиной в дубину - чтобы запаса в них было на 6000 пипсов..:)))) - только тогда прибыли получается 30 баксов на 10кило за полгода..:((((((((((
obla4ko: Точно! Не работает! Проскальзывает..:)) И много положительных позиций не открывает! А что предложите заместо него, родного?
Для этого надо знать требования. Можно вариант контроля открытия нового бара по времени - но устроит ли. Может сделки должны открываться в любое время. Проще контроль количества открытых позиций делать может. Вначале надо определиться - что нужно
1. История может изменятся. Фильтруются внутридневные гэпы, убираются выбросы и пр. Иногда даже дни пропадают! // Кто-то жаловался тут недавно, что месяц украли. Не ДЦ, а прям какой-то черт из "Вечеров на хуторе близ Диканьки"! )))
2. Разница может быть также из-за плавающего спреда. Тестер использует текущий на момент запуска.
3. История - не фигня. Фигня - это советник, который так зависит от таких мелочей.
нельзя советник уподоблять дубине - это вещь тонкая :))), виртуальная, я бы казала а вы что предлагаете, чтобы он не замечал как " дни пропадают! // Кто-то жаловался тут недавно, что месяц украли. "??? На ....н вообще такой советничеГ?
народ подскажите в индюках часто использует такое:
int CountedBars=IndicatorCounted();
if(CountedBars< 0) CountedBars= 0;
if(CountedBars> 0) CountedBars--;
cnt = Bars - CountedBars;
for(int i = 0; i < cnt ;i++)
если делать автоматизацию на основе такого то понятно что ничего сработает так как IndicatorCounted() будет 0. как правильно переделать начинку индюка что бы все работало?
Для этого надо знать требования. Можно вариант контроля открытия нового бара по времени - но устроит ли. Может сделки должны открываться в любое время. Проще контроль количества открытых позиций делать может. Вначале надо определиться - что нужно
а если просто вместо Volume[0]>1 прописать Volume[0] >5, скажем? Как отреагирует, по-вашему? Просто я - сторонник, по возможности, простых решений - онЕ самые гениальные!!:))
obla4ko:а по поводу тестирования на истории вопрос :
может ли советник (простенький!:)) - не сетка) на одной и том же отрезке истории,с одними и теми же параметрами давать совершенно различные результаты?
Единственное что, я, между этими двумя тестированиями, обновила архив котировок... и это могло привести к такому результату!? - тогда получается, что вся история - это фигня!?
1. История может изменятся. Фильтруются внутридневные гэпы, убираются выбросы и пр. Иногда даже дни пропадают! // Кто-то жаловался тут недавно, что месяц украли. Не ДЦ, а прям какой-то черт из "Вечеров на хуторе близ Диканьки"! )))
2. Разница может быть также из-за плавающего спреда. Тестер использует текущий на момент запуска.
3. История - не фигня. Фигня - это советник, который так зависит от таких мелочей.
также, по-моему, возможна "шпилька", в дальнейшем подчищенная..:)), но "сохраненная в памяти" более мелких таймфреймов, до которых уже не добраться...
а по поводу тестирования на истории вопрос :
может ли советник (простенький!:)) - не сетка) на одной и том же отрезке истории,с одними и теми же параметрами давать совершенно различные результаты?
Единственное что, я, между этими двумя тестированиями, обновила архив котировок... и это могло привести к такому результату!? - тогда получается, что вся история - это фигня!?
Спасибо за разъяснение - а как Вы считаете, нельзя ли вместо сравнения со значением Time[0] попробовать дать такое задание перед запросом OrderSend(...) : проверить, есть ли на текущем баре закрытие по StopLoss-y? Тогда нужно вводить функцию duble StopLoss(), которая будет работать с объявленной мною переменной StopLoss? Или это все-таки принципиально НЕ ВОЗМОЖНО? Мне важно, чтобы на баре, на котором поймали лося, новая позиция не открывалась, даже если по параметрам он подходит под открытие.
Дело в том, что ко временнЫм факторам хотелось бы обратиться в последнюю очередь - очень часто проскальзывают - вернее интерпретация приказа почему-то получается разнородной (неоднозначной)
Пришло несколько тиков зараз и уже больше единицыНа быстром рынке эта условие работать не будет
Пришло несколько тиков зараз и уже больше единицыНа быстром рынке эта условие работать не будет
Точно... сами только что писали о подтирании "шпилек". Плюс ещё при тестировании спред берётся текущий. А он может и различаться: на прошлом тесте он был 2 пункта, а на текущем стал 4, например...
Точно! Не работает! Проскальзывает..:)) И много положительных позиций не открывает! А что предложите заместо него, родного?
Для этого надо знать требования. Можно вариант контроля открытия нового бара по времени - но устроит ли. Может сделки должны открываться в любое время. Проще контроль количества открытых позиций делать может. Вначале надо определиться - что нужно
1. История может изменятся. Фильтруются внутридневные гэпы, убираются выбросы и пр. Иногда даже дни пропадают! // Кто-то жаловался тут недавно, что месяц украли. Не ДЦ, а прям какой-то черт из "Вечеров на хуторе близ Диканьки"! )))
2. Разница может быть также из-за плавающего спреда. Тестер использует текущий на момент запуска.
3. История - не фигня. Фигня - это советник, который так зависит от таких мелочей.
народ подскажите в индюках часто использует такое:
если делать автоматизацию на основе такого то понятно что ничего сработает так как IndicatorCounted() будет 0. как правильно переделать начинку индюка что бы все работало?
Для этого надо знать требования. Можно вариант контроля открытия нового бара по времени - но устроит ли. Может сделки должны открываться в любое время. Проще контроль количества открытых позиций делать может. Вначале надо определиться - что нужно
Для каждого советника свои требования