Максимальная просадка в детализированном отчёте сильно отличается от реальной. Вопрос разработчикам.

 

Вот отчёт с реального счёта. Максимальная просадка равна 199.48, хотя в реальности она была на этом интервале  раз в 10 больше. И связано это с тем, что максимальная просадка считается по закрытым сделкам, а просадка на интервале пока сделка не закрыта никак не учитывается.

Вопрос разработчикам:

Будет ли терминал когда-нибудь доработан так, чтобы максимальная просадка при работе учитывалась правильно, т.е. отслеживалась правильно на интервале времени, когда сделка ещё в рынке? Для этого, когда сделка в рынке, должен производиться расчёт максимальной просадки и текущая максимальная просадка должна храниться в каком-то буфере, а при формировании детализированного отчёта должна быть считана из этого буфера.

 

 
khorosh:

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

Если "буфер" будет на стороне клиента, то, очевидно, он не сможет отслеживать просадку на все 100%, т. к. мало у кого терминалы включены круглые сутки.

Если же предлагается внедрение такого "буфера" на сервере, то это приведет к дополнительной нагрузке на него, т. к. нужно будет вести статистику сразу по тысячам счетов. Вряд ли такое будет.

 

Решение проблемы, насколько мне видится, лежит в другой плоскости: при создании отчета производится моделирование рыночной ситуации (как в тестере). Но, во-первых, это достаточно нетривиальная задача, а, во-вторых, требует наличия тиковой истории. Причем, если символ сделки не содержит валюту счета, то потребуется тиковая история не по одному, а по двум символам (символ сделки + символ, в котором базовая валюта символа сделки котируется через валюту счета). Что уж говорить, если торговля велась на различных символах одновременно?

Так что вряд ли описанная проблема в ближайшем будущем будет решена штатно. Естественно, при помощи дополнительного софта ее решить можно (т. е. написать собственный "statement maker"). 

 
Scriptong:

Если "буфер" будет на стороне клиента, то, очевидно, он не сможет отслеживать просадку на все 100%, т. к. мало у кого терминалы включены круглые сутки.

Если же предлагается внедрение такого "буфера" на сервере, то это приведет к дополнительной нагрузке на него, т. к. нужно будет вести статистику сразу по тысячам счетов. Вряд ли такое будет.

 

Решение проблемы, насколько мне видится, лежит в другой плоскости: при создании отчета производится моделирование рыночной ситуации (как в тестере). Но, во-первых, это достаточно нетривиальная задача, а, во-вторых, требует наличия тиковой истории. Причем, если символ не содержит валюту счета, то потребуется тиковая история не по одному, а по двум символам (символ сделки + символ, в котором базовая валюта символа сделки котируется через валюту счета).

Так что вряд ли описанная проблема в ближайшем будущем будет решена штатно. Естественно, при помощи дополнительного софта ее решить можно (т. е. написать собственный "statement maker"). 

Для себя то я в советнике считаю максимальную просадку. Но хотелось бы, чтобы терминал в детализированном отчёте выдавал правильные данные. А то некоторые продавцы выкладывают отчёты для рекламы своих советников, а покупатели, видя такую маленькую просадку довольны и покупают продукт. А потом узнают, что в реальности просадка совсем не такая, какая была в отчёте.
 
khorosh:
Для себя то я в советнике считаю максимальную просадку. Но хотелось бы, чтобы терминал в детализированном отчёте выдавал правильные данные. А то некоторые продавцы выкладывают отчёты для рекламы своих советников, а покупатели, видя такую маленькую просадку довольны и покупают продукт. А потом узнают, что в реальности просадка совсем не такая, какая была в отчёте.
Что ж поделаешь... Всех людей не научишь. Более того, если они сами не хотят учиться, то тут и палка не поможет. Зачем смотреть на данные стейтмента, который легко подделать? Нужно смотреть хотя бы на данные мониторинга торговли
 
Scriptong:

Если "буфер" будет на стороне клиента, то, очевидно, он не сможет отслеживать просадку на все 100%, т. к. мало у кого терминалы включены круглые сутки.

Если же предлагается внедрение такого "буфера" на сервере, то это приведет к дополнительной нагрузке на него, т. к. нужно будет вести статистику сразу по тысячам счетов. Вряд ли такое будет.

 

Решение проблемы, насколько мне видится, лежит в другой плоскости: при создании отчета производится моделирование рыночной ситуации (как в тестере). Но, во-первых, это достаточно нетривиальная задача, а, во-вторых, требует наличия тиковой истории. Причем, если символ сделки не содержит валюту счета, то потребуется тиковая история не по одному, а по двум символам (символ сделки + символ, в котором базовая валюта символа сделки котируется через валюту счета). Что уж говорить, если торговля велась на различных символах одновременно?

Так что вряд ли описанная проблема в ближайшем будущем будет решена штатно. Естественно, при помощи дополнительного софта ее решить можно (т. е. написать собственный "statement maker"). 

Могли бы сделать расчёт просадки хотя бы на минутках, по ценам открытия. Величина  просадки по тикам и по ценам открытия минуток будет отличаться не более чем на 10%. По крайней мере не в 10 раз, как сейчас разница с реальностью.

Причина обращения: