Блог им. HOME

Робострой: вопрос из "зала" о неисполненных заявках. Просто поделиться опытом.

   Полагаю, мой ответ на нижеприведенный вопрос должен стать достоянием всех.
  
Сегодня утром коллега задал вопрос:
Часто в тестировании используют методы бек/форвард тест, иногда устраивают стресс тест, на хаотичных котировках, но в данном примере хотелось показать как смоделировать ситуацию, когда в алгоритме все хорошо, но по той или иной причине нашу заявку не исполнили.

Мой ответ (в 3-х частях, по мере внесения уточнений и подробностей) ему был следующий:

1. Все перечисленные «проблемы» решаются очень просто и успешно, если немного расширить само понятие «робот».
Добавьте надстройку, следящую за состоянием робота, за состоянием сети, инета, которая автоматически блокирует ненужные явления (задваивание ордеров на одном баре, например, или обрыв связи с сервером), и проблем не будет. Да, это выходит за рамки Lua (или того, на чем реализован робот). У меня такие сервисы реализованы на C#, опять же например. Итог: сам включается/выключается, «фильтрует базар» и поддерживает постоянное подключение, «постукивая» мне логами на почту или джаббер…

(тут следует уточняющий вопрос коллеги...)

2. ОК, расширю ответ: все неисполненные по каким-либо причинам ордера мой робот запоминает и при первой же возможности реализует. Сам! Я не влезаю в его работу, он сам решает проблему. Сам снимает, сам восстанавливает.
Главный закон моего робота: сигналы должны быть корректны и всегда исполнены на 100%.

(тут следует еще один уточняющий вопрос коллеги...)

3. Микаелян Саро, у меня робот ВСЕГДА  исполняет сигнал. Для того, чтобы ордер был реализован, в моем роботе предусмотрен алгоритм сопровождения ордера в торговой системе. Он перемещает ордер, изменяет цену, объем — всё, что нужно, лишь бы выполнить главное — реализовать сигнал на 100%.
Ну, а то, что цена на рынке не совпадает с какой-то «расчетной», — это просто может стать результатом, что расчет, выполненный до сего момента, оказался неверным в настоящий момент, и его нужно скорректировать с учетом «момента».

Иллюстрация к моим ответам (в нотации IDEF0) — трехконтурная архитектура автономного торгового комплекса:

Робострой: вопрос из "зала" о неисполненных заявках. Просто поделиться опытом.



★7
42 комментария
красивая диаграмма
avatar
SMisSCks, как говорил один весьма талантливый авиаконструктор, «некрасивые вещи не летают» )))
avatar
Вы слегка суть не уловили статьи. В ней говорится о том как искажается реальные результаты относительно тестовых  при моделировании не исполнении сигнала по расчетным значениям. То что система автономна и перевыставит заявки никто не спорит.
avatar
Микаелян Саро, Я не спорил с Вами, коллега, раньше и не спорю сейчас. Еще раз уточню: закон жизни моего робота — это выработка 100% корректного сигнала и 100%-ная же реализация этого сигнала. История бэк-тестирования неразрывна с текущей ситуацией! Мой робот торгует одинаково: что в бэк-тесте, что «в бою». Мало того, если текущая чистая открытая позиция в какой-либо момент времени отличается от расчетной по бэк-тесту, то робот автоматически выравнивает текущую позицию до тестовой.
avatar
Eugene Bright, одинаково торгует, чтотв бек тесте, чтотв бою? Да ладно привирать. Никогда на 100 ппоцентов моделирование в тесте не будет совпадать с входами и выходами, те рынок это живое существо. Вы хороший теоретик похоже.
avatar
GoodBargains, а Вы — жертва Крюгера-Даннинга.
avatar
 Возможно у вас с оппонентом разные представления о роботах. Нередко под более модным соусом продают фактически старую бизнес-модель робота.По принципу ещё древнего Метастока, выполнилось некоторое условие --> пуляется заявка по рынку, а дальше логика включается, только на «выход» по противоположному сигналу.
avatar
Anest, да, очень вероятно, что Вы правы. Ну, тогда мои скромные замечания должны побудить читателей «расширить» это представление до, действительно, настоящего робота, т.е. максимально возможно автономной системы с минимальным человекоучастием. )))
avatar
А если на одном и том же баре цена верха и низа попадает под алгоритм. Допустим, открытия или закрытия сделки. ДВАЖДЫ!!! и закрытие и открытие и закрытие и открытие.
Как в тесте робот сможет прогнать такой вариант?

Часто подобная ситуация переворачивает результаты.

Допустим: Есть открытая. Диапазон достигнут, надо закрыть и развернуть.
Но тут же есть и в обратной стороне свечи добрать или отстопиться.
В итоге может получиться, что взята увеличенная поза по экстремуму и против себя.
Ну не на «тиках» же у Вас робот, который по «свечам» (сужу по описанию)?!!!
avatar
GrayFox, а это, коллега, секрет фирмы! Да, такие ситуёвины, конечно же нередки, но робот заточен и на решение таких проблем…
avatar
Eugene Bright, Согласен. Полагаю, речь про КВИК.
В том же МТ я решал проще — маркерами, которые просто прямо к заявке присасываются и сопровождают ордер-исполнение-закрытие на всём протяжении алгоритма робота… именно «РОБОТА»...

В иных — надо самому приблуду делать ))))

Секретик: «Маркер» — хорошее слово для заявки.

А когда у тебя используется 10+ инструментов сразу — тем более ))))
avatar
GrayFox, "… аналогично, шеф!"©
avatar
Eugene Bright, «Ничего не понимаю..» «коллега»
))))
avatar
GrayFox, да и на тиках не будет совпадать. Если б он торговал реально знал бы отчем речь идет)) если на цене нет ликвидности, то в реале сделки по той цене никогда не будет, а в тесте будет. А это два совершенно разных алгоритма) Отследить чтобы сделка была или не было задвоений вообще не проблема. А вот отсутсвие ликвидности для сделки в реале- это проблема всех проблем
avatar
 А неисполненные отслеживаются всегда легко. Достаточно вести отдельную таблицу/массив, который сравнивает последнюю сделку с предыдущей заявкой (в т.ч. по полноте исполнения).
Есть заявка — попала в данные свои очередной строкой.
Есть исполнение (добивка строки заявки в столбце сделок) — проверка на полноту.
Появилась новая заявка, когда прошлая строка не заполнена — значит прошлая не исполнена (ну или исполнена частично, если идёт сравнение объема).

Это же очень просто.
avatar
GrayFox, в общем, так. Конкретные реализации могут разниться, но смысл Вы верно указали.
avatar
GrayFox, в Trans2Quik же есть коллбэки — Order_StatusCallback b Trade_Status_Callback , с ними проще будет, Хотя конечно реализовать можно по разному.
avatar
Anest, (если позволите «встрять» в Вашу беседу) коллега Микаелян Саро работает не в КВИКе, насколько я понял, а на TSLab.
И потом, вопрос-то не в том, что нужно узнать состояние ордера и транзакции, когда ордер уже подан в систему, а как раз тогда, когда робот выработал сигнал, а ордер в систему не попадает, т.е. сигнал «пропал».
avatar
Eugene Bright, Вполне возможно, мы тут каждый, на своей«волне» и со своими «тараканами» :)
avatar
Anest, "… это не просто факт. Это — гораздо больше, чем факт: так оно и было на самом деле!" © (к/ф «Тот самый Мюнхгаузен»):



avatar
Eugene Bright, как пропал? как в систему не прошёл ордер? Есть же всегда в любой приблуде «контроль ошибок»… отклик… Да или нет… при том с кодом ошибки.
avatar
GrayFox, вот коллега Микаелян Саро как раз об этом и спрашивает: как быть-то?
avatar
Eugene Bright, так и быть… от системы получать отклик ошибки ли ОК… 0 или конкретика...
Есть иной вариант? если не на низкоуровневом пишешь?
Во всех приблудах есть отклик!!!!
Его и проверять!!
(при тестирование есть ли такое — не знаю, потому что в боевых всегда проверял, однако)
avatar
GrayFox, вот я и пытался его навести на мысль. Видимо, получилось как-то коряво...
Ну, что ж, не мастер я, не мастер.
avatar
Eugene Bright, да нормально на мысль наведено, просто слишком много остального. Я попытался добавить, что это реально просто.
С ПРИБЛУДАМИ для программирования — просто (отклик) ...
Без приблуд на машинном — сразу надо закладывать отдельным блоком контроля исполнения.
avatar
GrayFox, да, конечно!
avatar
Eugene Bright, спачибо за вечер. Доставило писать тут.
avatar
GrayFox, спасибо за содержательную беседу! Приятно общаться с единомышленниками.
avatar
Eugene Bright, надо держаться вместе! Нас так мало!!!
(осталось)
avatar
Eugene Bright, Вспомнил (вроде бы) Павловский дворец… под Питером… Там большой кирпичный тоннель. и красивое Эхо ...
Если крикнуть «Кто украл хомуты?» — ответ через пару секунд «ты-ты-ты» ...
Все всегда хотели при экскурсоводе крикнуть «Кому не спится в ночь глухую???» ..
Вот так ответ и получается.

Если крикнул одно, а получил иное — значит косяк.

Это и надо проверять ))))
avatar
GrayFox, главное в общении с Эхом — это не обижаться на ответы! )))
avatar
Eugene Bright, ага…
avatar
GrayFox, чот не работает эхо в этом тоннеле, как мой ребёнок ни орал, адекватный коллбэк не приходит
avatar
Anest, всё равно для алгоритма (не знаю его) надо отследить исполнение заявки. И количество и вообще исполнение.
Иначе можно получить полную чехарду.
Алгоритм рабочий, но за счет факта исполнения/неисполнения/частичного — он может просто привести к совсем иным результатам… а при бэктесте — только на тиках. ЧАСТО МОЖЕТ БЫТЬ ДВИГ В ОБЕ СТОРОНЫ ДАЖЕ НА МИНУТЕ, который попадает под алгоритм со всех сразу блоков принятия решения. Тут вопрос очередности блоков, однако, бектест не даст такого результата, какой вживую.

Могу четко сказать… одного из роботов я ещё лет 5 назад сажал на боевой счет и потом делал бектест на минутках (он не по барам работал)...

Итог плачевен.

Боевой + 120% за 6 мес… Тестовый — -40% на одном и том же периоде.
avatar
GrayFox, 
Это же очень просто.

Это очень просто только в одном случае, в случае «лабораторных условий».
В реальной жизни, когда торгуется несколько сотен алгоритмов с разнообразными правилами выставления ордеров, с большим количеством ордеров и сделок по многим инструментам за торговую сессию, эта простая задача превращается в весьма сложную.
Дмитрий Овчинников, да… потому от частного к общему. Не так ли?
Вопрос в том, как избежать ошибок при тесте.
avatar
GrayFox, 
тесты, к сожалению, не способны при всех ухищрениях тестирующих, смоделировать те ситуации и ошибки, которые возникнут в реальной торговле ;)
Дмитрий Овчинников, всё зависит не от мастерства и «хитростей», а от четкости и конкретности заложенной в тесты стратегии.
avatar
Eugene Bright, 
да я же не спорю, тестируйте на здоровье. Но все в итоге будет зависеть от опыта. А его в тестах не найдете :)
Дмитрий Овчинников, конечно, не найдете. Чтобы найти, нужно знать, что ищешь. Как сказал один неглупый человек, «правильно заданный вопрос — это уже 90% ответа».
avatar
что то не понял я о чем пост? о том что надо не просто послать заявку, но и проконтролить ее исполнение, дак это очевидные вещи по-моему, нет? ибо все время какие-то лаги происходят то обрыв, то неконнект некоторое время и пропущенный момент…
avatar
Виталий, пост о том, как помочь коллеге в его проблеме (приведена цитата в начале поста):
Часто в тестировании используют методы бек/форвард тест, иногда устраивают стресс тест, на хаотичных котировках, но в данном примере хотелось показать как смоделировать ситуацию, когда в алгоритме все хорошо, но по той или иной причине нашу заявку не исполнили.
avatar

теги блога Eugene Bright

....все тэги



UPDONW
Новый дизайн