Сообщений в теме: 35

[Olej]

Эта тема возникла вот отсюда:
http://fxgeneral.com...topic=60&st=180
- из вопросов тестирования советников для автоматической ТС.

Чтобы не сваливать всё в кучу.
Т.е. к вопросам "технологии испытания советника", ... возникают вот такие вопросы:
- вот прогнали по-верхам тесты нового советника - в роде как ничего ... что дальше?
- наверное на демо переставлять ... а какой объём тестирования считать достаточным? чтобы переходить на демо счёт... (это вопрос №1)
- как организовать прогоны/тестирование на демо счёте ... а здесь вопросы и вопросы:
- ... нужно ли гонять демо круглосуточно? или время от времени? (это вопрос №2)
- как и где можно установить советник для демо-прогонов на нешний сервер? вот здесь как раз вчера затронули в обсуждениях:
http://fxgeneral.com...opic=454&st=100
... но так ни до чего путного и не договорились... (это вопрос №3)
- как долго гонять по демо, чтобы считать достаточным для перехода на реал? (это вопрос №4)
- какие особенности отличают демо от теста в MT4, и на что особенно обращать внимание? (это вопрос №5)

Вот сколько вопросов вызывает одна тема!

Какие могут быть мнения на этот счёт?

[Darvin]

Я бы после недели на демо сразу бы загонял на центовый реал,так как на демо и реале совсем разное исполнение,если советник скальпер или что-то в этом роде, то демка может сильно отличаться от реала..

[Olej]

Я бы после недели на демо сразу бы загонял на центовый реал,так как на демо и реале совсем разное исполнение

Это да, это есть.

Но ещё интереснее ... может у вас какое мнение на этот счёт будет? :

- почему результаты тестов советников в MT4 от разных ДЦ, а значит и разных серверов источников котировок - отличаются?

- и на демо счетах разных ДЦ результаты одного и того же советника будут отличаться?

- а на реалах, но счета от разных ДЦ?

- и означает ли это, что протестированный на исторических данных одного ДЦ советник, на реальных счетах другого ДЦ окажется ... не совсем так хорош, как "на том" ДЦ?

Может у кого-то есть какие-то наблюдения по вот этим "странным" вещам? Или соображения?

[DimaExtreme]

- и означает ли это, что протестированный на исторических данных одного ДЦ советник, на реальных счетах другого ДЦ окажется ... не совсем так хорош, как "на том" ДЦ?

Может у кого-то есть какие-то наблюдения по вот этим "странным" вещам? Или соображения?

Вот что я точно заметил, так это то, что на Альпари я протестировал и про оптимизировал советника (не важно какой), а на Екснесс он показал совсем не те результаты и пришлось его оптить заново.
А в общем у меня тоже есть непонятки по тестированию и оптимизации:
- все в округе советуют тестировать советника в периоде 2-х лет отступая в 6 мес от текущей даты, а потом проводить форвардное тестирование. А в Форекс клубе вообще советуют начинать с периода в 5-ть лет! Но ведь братцы, рынок ведь меняется! Даже слепой сможет разглядеть это! Я сам ещё конечно не определился точно с периодом, но считаю, что смысла в двух годичном тестировании НЕТ! А не давно один собрат вообще мне написал следующее, что ОПТИМИЗАЦИЯ - ЭТО ПОДГОНКА ПОД ИСТОРИЮ!!!!! Тогда вопрос, а что собственно такое как ТЕСТИРОВАНИЕ НА ДВУХ ЛЕТНЕМ ПЕРИОДЕ? Я полагаю, что всё же если и проводить тестирование, то в периоде максимум год, ну если точнее, то 9 мес, а остальное это форвардное тестирование и оптимизация. Это конечно моё мнение, но хотелось бы услышать и другие точки зрения по этому вопросу. А?

Сообщение отредактировал DimaExtreme: 05 February 2011 - 16:22

[Olej]

Вот что я точно заметил, так это то, что на Альпари я протестировал и про оптимизировал советника (не важно какой), а на Екснесс он показал совсем не те результаты и пришлось его оптить заново.

Хорошие вопросы!
Для того, чтобы понимать, что дают нам тесты (да и демо счета), насколько их результатам можно доверять, и что они вообще означают...

Я буду по частям отвечать...

1. 1-я причина расхождений результатов на разных ДЦ, вплоть до противположных - это значность (4 или 5) используемая ДЦ, и значения, указываемые для настроечных переменных размерности "пункт" ... чаще всего это SL & TP, но могут быть и другие ... для вариантов Мартингейла это часто сдвиг уровней отложенных ордеров...

Пример: для одинаковых условий нужно указывать, например, SL=100 & TP=200 для Alpari, но то же самое как SL=10 & TP=20 для InstaTrader или NordFX...
И не всегда (не во всех советниках) такая простая "нормировка" (деление/умножение на 10) даёт корректный результат.

Но это, так сказать, эффект невнимательности тестирующего (или плохого написания автором советника)...
Есть куда интереснее ... "фичи"

[Olej]

Есть куда интереснее ... "фичи"

Рассмотрите какое-то характерное место графиков котировочных от разных ДЦ (сравнительно).

Можете рассмотреть следующее:
- EURUSD M5, 4.02.2011 ... около 14:30 ... - после длинного флэта там резкий облом вниз, 2 длинные свечи вниз...
- вот их и рассматривал я на разных ДЦ, причём у меня на компьютере в это время стоит локальное время 19:00...
- я выпишу для разных ДЦ : время 1-й свечи - её максимальное значение - ... - время последней на сегодня текущей у меня закрытого бара (7.02 19:00) :

NordFX - 14:30 - 1.3677 - 18:00
Forex4you - 14:40 - 1.3679 - 18:00
InstaForex - 15:30 - 1.3677 - 19:00
Alpari - 14:30 - 1.36756 - 18:00

- что вообще укзывается на шкале времени графика? какое время? время сервера? в его часовом поясе?

[Olej]

- что вообще укзывается на шкале времени графика? какое время? время сервера? в его часовом поясе?

Что отсюда прямо следует? :

1. результаты тестирования просто должны отличаться, потому что период тестирования "от" и "до" можно задать в датах, но не времени, и одни и те же периоды на разных ДЦ будут попадать в разные даты!
2. что на бОльших тайм-слотах ... H4 и далее - сами котировочные бары станут различаться, потому как будут включать в своё формирование разные бары меньших тайм-фреймов.

Но и это ещё не всё!

Реально в рынке нет никаких "баров" и нет никаих "тайм-фреймов" - всё это выдумки... а есть "тиковые" котировки, которые следуют с примерным периодом (плавающим) в 1 сек., и их которых ... ну очень странным образом формируются бары, которые есть только "пачки" тиковых данных: M1 - 60 тиков, M5 - 300 и т.д.

Почему очень странным?
Посмотрите на такую последовательность котировок из 10 тиков (а реально в баре их может быть таких многие сотни):
10, 1, 1, 1, 1, 1, 1, 1, 1, 10 - в результате будет бар OHLC: 10, 10, 1, 10 ... что можно принять за высокие цены...
10,9, 8, 7, 6, 5, 4, 3, 2, 10 - OHLC: 10, 10, 2, 10 ... никаких трендов, спокойный бар с высокими ценами...

Но вернёмся к эффектам времени и тестирования...

Поскольку на серверах - свои временные шкалы ... мало того, что они не синхронизированы, но сервере ... мне кажется - не синхронизируют свои часы от цезиевого стандарта времени, или даже GPS... времена их могут, пусть немного, отличаться...
Но из-за этого расхождения одни тики будут попадать в предшествующие бары, а другие в последующие, и это "размежевание" на разных серверах будет происходить по-разному... а значит и котировочные последовательности будут отличаться (часто малозаметно, но из-за ... "странного формирования бара" временами и ... ?), и результаты тестов будут плавать!

[swi-1]

Что отсюда прямо следует? :

1. результаты тестирования просто должны отличаться, потому что период тестирования "от" и "до" можно задать в датах, но не времени, и одни и те же периоды на разных ДЦ будут попадать в разные даты!
2. что на бОльших тайм-слотах ... H4 и далее - сами котировочные бары станут различаться, потому как будут включать в своё формирование разные бары меньших тайм-фреймов.

Но и это ещё не всё!

Реально в рынке нет никаких "баров" и нет никаих "тайм-фреймов" - всё это выдумки... а есть "тиковые" котировки, которые следуют с примерным периодом (плавающим) в 1 сек., и их которых ... ну очень странным образом формируются бары, которые есть только "пачки" тиковых данных: M1 - 60 тиков, M5 - 300 и т.д.

Почему очень странным?
Посмотрите на такую последовательность котировок из 10 тиков (а реально в баре их может быть таких многие сотни):
10, 1, 1, 1, 1, 1, 1, 1, 1, 10 - в результате будет бар OHLC: 10, 10, 1, 10 ... что можно принять за высокие цены...
10,9, 8, 7, 6, 5, 4, 3, 2, 10 - OHLC: 10, 10, 2, 10 ... никаких трендов, спокойный бар с высокими ценами...

Но вернёмся к эффектам времени и тестирования...

Поскольку на серверах - свои временные шкалы ... мало того, что они не синхронизированы, но сервере ... мне кажется - не синхронизируют свои часы от цезиевого стандарта времени, или даже GPS... времена их могут, пусть немного, отличаться...
Но из-за этого расхождения одни тики будут попадать в предшествующие бары, а другие в последующие, и это "размежевание" на разных серверах будет происходить по-разному... а значит и котировочные последовательности будут отличаться (часто малозаметно, но из-за ... "странного формирования бара" временами и ... ?), и результаты тестов будут плавать!

Очень интересное и вдумчивое исследование!
Спасибо. Многие моменты становятся понятными при таком объяснении.
Ваши выводы частично отвечают на Ваши же вопросы, поставленные ранее.
Получается, что моделирование "хаоса" в принципе не может быть точным.
Отсюда вытекают и субъективизм оценок тестирования и отсутствие "стандартов" в этом вопросе .
И все-таки, надо до чего -то договариваться и приходить к единому пониманию целей, средств и возможностей тестирования.

[Michelangelo®]

... "пачки" тиковых данных: M1 - 60 тиков, M5 - 300 и т.д.

с чего это взял? т.е. с чего ты взял что в М1 всего (или не более 60 тиков?), а в М5 всего (или не более 300)? по моему немного бредишь... сори за грубость...

[Olej]

с чего это взял? т.е. с чего ты взял что в М1 всего (или не более 60 тиков?), а в М5 всего (или не более 300)? по моему немного бредишь... сори за грубость...

А это легко проверить: написать простейший советник, который по Alarm() будет выводить время прихода тика (время очередного входа в start()).
Я видел в этой последовательности почти строгие 1 тик в секунду, с некоторыми провалами, естественно, поскольку это завязано с трафиком, загрузкой линий = задержками на сокетных операциях в OS (в стеке IP ... я свои пробы проделывал в Linux, но не думаю, что картина сильно поменяется) ... потом возникающие провалы в потоке - навёрстываются более плотной доставкой данных...
Это всё нужно перепроверять, но, по моему это так.

Если поток тиковых котировок идёт с интенсивностью сек^-1 то в пачке тиков (баре) M1 и будет укладываться ~60 тиков-котировок.

[Michelangelo®]

А это легко проверить: написать простейший советник, который по Alarm() будет выводить время прихода тика (время очередного входа в start()).
Я видел в этой последовательности почти строгие 1 тик в секунду, с некоторыми провалами, естественно, поскольку это завязано с трафиком, загрузкой линий = задержками на сокетных операциях в OS (в стеке IP ... я свои пробы проделывал в Linux, но не думаю, что картина сильно поменяется) ... потом возникающие провалы в потоке - навёрстываются более плотной доставкой данных...
Это всё нужно перепроверять, но, по моему это так.

Если поток тиковых котировок идёт с интенсивностью сек^-1 то в пачке тиков (баре) M1 и будет укладываться ~60 тиков-котировок.

предположим, что тики идут со скоростью 1 тик в секунду, тогда да... М1=60 тиков, М5=300 тиков... но!!! тики идут с точностью до предложения новой цены... т.е. не 1 тик в сикунду (об этом нам говорит переменная Volume[])... так что в нашем, М1.М5.М15 и т.д. - единицы времени, а не количество тиков!!! т.е. М1 бар начался в 0:00:00 с приходом первого (возможно единственного тика)... и окончился в 0:00:59 независимо от прихода последнего тика...
первый тик мозжет придти и не в 0:00:00, но обязательно в промежуток времени от 0:00:00 до 0:00:59...

[Olej]

М1.М5.М15 и т.д. - единицы времени, а не количество тиков!!! т.е. М1 бар начался в 0:00:00 с приходом первого (возможно единственного тика)... и окончился в 0:00:59 независимо от прихода последнего тика...

Конечно M1, M5, ... - это единицы времени, а где я говорил противоположное?

Я говорил только о средней плотности потока тиков (обновлений). И она практически постоянная (хоть это и не важно).
Вот чем-то подобным такому можно посмотреть, по-быстренькому состряпал...

extern bool bDebug = false;
int nBars = 0, Tick = 0;

int start() {
   if( nBars != Bars ) {                            // начался новый бар ...
      nBars = Bars;
      Alert( TimeToStr( TimeCurrent(), TIME_SECONDS ),
             " => #", Bars, " : ", Tick );
      Tick = 0;
   }
   Tick++;
   if( bDebug ) 
      Alert( TimeToStr( TimeCurrent(), TIME_SECONDS ),
             " => #", Bars, " : ", Tick );
}

Но что интересно, раньше я этого не смотрел, частота потока обновлений от разных ДЦ - очень сильно различается...

Раньше я смотрел только для Alpari, вот сейчас у меня цифры (тиков в интервал M1): 43-58, в основном, но есть и 26...

Но! От InstaTrader это: 5, 6, 7... изредка 15, 23.

Forex4you это 2-4, изредка 6-7.
NordFX: 10-13-14 ... иногда 6-7.

[Olej]

т.е. не 1 тик в сикунду (об этом нам говорит переменная Volume[])...

Относительно Volume[] и как оно связано - я не понял.
Расскажите подробнее.

[Michelangelo®]

Относительно Volume[] и как оно связано - я не понял.
Расскажите подробнее.

Volume[] - количество операций в баре (т.е. тиков...) проверьте со своей функцией... выше по тексту...
(я уже не так трезв, но трезв, имхо...)

[Olej]

Volume[] - количество операций в баре (т.е. тиков...) проверьте со своей функцией...

Посмотрел. Похоже ... хотя иногда выскакивает различие в 1-2 единицы... (причём всегда Volume[] в большую сторону).
За такую подсказку спасибо. ... посмотрел то же на M5 - здесь расхождения уже поболее, до 4 единиц, и тоже в большую сторону.

Не совсем мне понятно вот что: а). как-то думалось, что смысл значения Volume[] более содержательный, б). кокой тогда реальный смысл значения Volume[]?

... далее, с выявившимися различиями с частотами тиков (частотами обновления) от разных ДЦ - соотносить результаты тестирования на историях разных ДЦ становится ещё проблематичнее.