Тестер работает корректно ? - страница 5

 
Integer:
Нда... поторопился я.... Оказывается есть бары у которых цена открытия равна цене закрытия предыдущего. Тогда по какой же системе МТ бары рисует? Наверно только разработчики смогут объяснить. Очень бы хотелось понять.

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

Если используются только наши рилтаймовые данные и нет межсессионных разрывов или рестартов сервера, то Close одного бара не может быть равен Open последующего. Если же используются импортированные данные, то такое может быть.
 
Renat:
Integer:
Нда... поторопился я.... Оказывается есть бары у которых цена открытия равна цене закрытия предыдущего. Тогда по какой же системе МТ бары рисует? Наверно только разработчики смогут объяснить. Очень бы хотелось понять.

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

Если используются только наши рилтаймовые данные и нет межсессионных разрывов или рестартов сервера, то Close одного бара не может быть равен Open последующего. Если же используются импортированные данные, то такое может быть.
Такое есть в любых данных минутного тф - можете сами убедиться и в тех котировках, что я скачивал с Альпари, вроде, тоже.



Вот пример : котировки реал тайм, Ваш демосервер. Смотрите выделенный бар и двумя барами выше. На выделенном баре значение тикового объема должно быть равно 0. Поскольку изменение цены до данного уровня учтено в тиковом объеме предыдущего бара.
Двумя же барами выше 1 стоит верно.

И это случай не единичный. Просмотрите историю. Думаю, дело здесь не в реквотах.

Потому вопрос и возник.

Успехов. С уважением, Владислав.

ЗЫ Сорри - данный пример не верен - не туда глянул. Сейчас поищу в другом месте.
ЗЗЫ Прогнал скриптом Ваши данные - глазами боялся ошибиться еще раз - в тех, что я получал реалтайм с Вашего сервера действительно такого нет. Так что вопрос снимаю.

Успехов. С уважением, Владислав.
 
VladislavVG:
Renat:
Integer:
Нда... поторопился я.... Оказывается есть бары у которых цена открытия равна цене закрытия предыдущего. Тогда по какой же системе МТ бары рисует? Наверно только разработчики смогут объяснить. Очень бы хотелось понять.

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

Если используются только наши рилтаймовые данные и нет межсессионных разрывов или рестартов сервера, то Close одного бара не может быть равен Open последующего. Если же используются импортированные данные, то такое может быть.
Такое есть в любых данных минутного тф - можете сами убедиться и в тех котировках, что я скачивал с Альпари тоже.

Вот пример : котировки реал тайм, Ваш демосервер. Смотрите выделенный бар и двумя барами выше. На выделенном баре значение тикового объема должно быть равно 0. Поскольку изменение цены до данного уровня учтено в тиковом объеме предыдущего бара.
Двумя же барами выше 1 стоит верно.

И это случай не единичный - такое есть всегда. То есть, если высказываться более корректно, я не нашел ни одного бара, где бы в выделенном случае стоял ноль. Просмотрите историю. Думаю, дело здесь не в реквотах.

Потому вопрос и возник.

Успехов. С уважением, Владислав.


А что Вы хотели показать этим примером? Бар-додж из одной котировки (OHLC = одной цене)?
Так это абсолютно нормальная ситуация. Никаких ошибок или разночтений нет.
 
Renat:
VladislavVG:
Renat:
Integer:
Нда... поторопился я.... Оказывается есть бары у которых цена открытия равна цене закрытия предыдущего. Тогда по какой же системе МТ бары рисует? Наверно только разработчики смогут объяснить. Очень бы хотелось понять.

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

Если используются только наши рилтаймовые данные и нет межсессионных разрывов или рестартов сервера, то Close одного бара не может быть равен Open последующего. Если же используются импортированные данные, то такое может быть.
Такое есть в любых данных минутного тф - можете сами убедиться и в тех котировках, что я скачивал с Альпари тоже.

Вот пример : котировки реал тайм, Ваш демосервер. Смотрите выделенный бар и двумя барами выше. На выделенном баре значение тикового объема должно быть равно 0. Поскольку изменение цены до данного уровня учтено в тиковом объеме предыдущего бара.
Двумя же барами выше 1 стоит верно.

И это случай не единичный - такое есть всегда. То есть, если высказываться более корректно, я не нашел ни одного бара, где бы в выделенном случае стоял ноль. Просмотрите историю. Думаю, дело здесь не в реквотах.

Потому вопрос и возник.

Успехов. С уважением, Владислав.


А что Вы хотели показать этим примером? Бар-додж из одной котировки (OHLC = одной цене)?
Так это абсолютно нормальная ситуация. Никаких ошибок или разночтений нет.
Да, я уже увидел и поправил предыдущий пост.

Успехов. С уважением, Владислав.
 
VladislavVG:

ЗЫ Сорри - данный пример не верен - не туда глянул. Сейчас поищу в другом месте.
ЗЗЫ Прогнал скриптом Ваши данные - глазами боялся ошибиться еще раз - в тех, что я получал реалтайм с Вашего сервера действительно такого нет. Так что вопрос снимаю.


Да, я тоже написал скрипт для проверки условия if(Close[previous]==Open[current]) и обнаружил такое только на импортированных данных. На наших рилтаймовых данных такого нет.
 
Renat:
VladislavVG:

ЗЫ Сорри - данный пример не верен - не туда глянул. Сейчас поищу в другом месте.
ЗЗЫ Прогнал скриптом Ваши данные - глазами боялся ошибиться еще раз - в тех, что я получал реалтайм с Вашего сервера действительно такого нет. Так что вопрос снимаю.


Да, я тоже написал скрипт для проверки условия if(Close[previous]==Open[current]) и обнаружил такое только на импортированных данных. На наших рилтаймовых данных такого нет.
Я правильно понимаю, что тестер должен сильно искажать тесты при такой ситуации? Возможно стоит добавить такую проверку в стандартный скрипт ? Понятно, что лучше для тестов пользоваться выверенными данными. Но многие трейдеры тестируют системы на данных своего брокера - возможны недоразумения.

Успехов. С уважением, Владислав.
 
VladislavVG:

Да, я тоже написал скрипт для проверки условия if(Close[previous]==Open[current]) и обнаружил такое только на импортированных данных. На наших рилтаймовых данных такого нет.
Я правильно понимаю, что тестер должен сильно искажать тесты при такой ситуации? Возможно стоит добавить такую проверку в стандартный скрипт ? Понятно, что лучше для тестов пользоваться выверенными данными. Но многие трейдеры тестируют системы на данных своего брокера - возможны недоразумения.

Успехов. С уважением, Владислав.
Абсолютно неправильно. Нет никакого искажения, кроме ошибочных мыслей об одном пипсе в головах трейдеров.

Поймите, что в тестировании Вы не должны никогда надеяться на тики. Вы наоборот должны не обращать внимания на шумовые движения в пределах полспреда-спреда. Практически каждый трейдер проходит через банальную пипсовку с надеждой о возможности вырвать лишний пипс. И также большинство трейдеров оправдываются "нет, я не пипсовщик, я ратую за точное исполнение!" :)

Люди сами себя обманывают, надеясь на абсолютно точное и гарантированное исполнение, а потом удивляются тому, что в реальности им дают реквоты, а на быстром рынке невозможно совершить сделку. Мало того, многие вообще не занимаются обработкой реквотов и других ответов торгового сервера.
 
Renat:
VladislavVG:

Да, я тоже написал скрипт для проверки условия if(Close[previous]==Open[current]) и обнаружил такое только на импортированных данных. На наших рилтаймовых данных такого нет.
Я правильно понимаю, что тестер должен сильно искажать тесты при такой ситуации? Возможно стоит добавить такую проверку в стандартный скрипт ? Понятно, что лучше для тестов пользоваться выверенными данными. Но многие трейдеры тестируют системы на данных своего брокера - возможны недоразумения.

Успехов. С уважением, Владислав.
Абсолютно неправильно. Нет никакого искажения, кроме ошибочных мыслей об одном пипсе в головах трейдеров.

Поймите, что в тестировании Вы не должны никогда надеяться на тики. Вы наоборот должны не обращать внимания на шумовые движения в пределах полспреда-спреда. Практически каждый трейдер проходит через банальную пипсовку с надеждой о возможности вырвать лишний пипс. И также большинство трейдеров оправдываются "нет, я не пипсовщик, я ратую за точное исполнение!" :)

Люди сами себя обманывают, надеясь на абсолютно точное и гарантированное исполнение, а потом удивляются тому, что в реальности им дают реквоты, а на быстром рынке невозможно совершить сделку. Мало того, многие вообще не занимаются обработкой реквотов и других ответов торгового сервера.
Да я, вобщем, никогда и не надеялся на точное исполнение. И по поводу тиков прекрасно понимаю. У меня вообще все стопы идут за пределами статистически значимых разворотных зон и уж не ближе, чем 2,5 АТР за экстремумом предыдущего бара :). То есть, нет даже намека на "пипсовочные" алгоритмы. По поводу спреда-полспреда я бы даже сказал, что более точной оценкой является значение, выраженое в АТР (проверено практикой).

Хотелось узнать насколько такие "помехи" (назовем их так) смогут повлиять на качество работы самого тестера. Я же писал выше, что саму стратегию не рассматриваю.
Из Вашего ответа делаю вывод, что не смогут. Отрадно.

Успехов. С уважением, Владислав.
 
Renat писал (а):

Если используются только наши рилтаймовые данные и нет межсессионных разрывов или рестартов сервера, то Close одного бара не может быть равен Open последующего. Если же используются импортированные данные, то такое может быть.

У меня не импортированные данные, а закаченные в МТ "законным путем" от ДЦ.
 
Integer:
Renat писал (а):

Если используются только наши рилтаймовые данные и нет межсессионных разрывов или рестартов сервера, то Close одного бара не может быть равен Open последующего. Если же используются импортированные данные, то такое может быть.

У меня не импортированные данные, а закаченные в МТ "законным путем" от ДЦ.
Значит они были импортированы в торговый сервер - такое часто встречается для исторических данных ранних периодов.
Причина обращения: