Полагаю, мой ответ на нижеприведенный вопрос должен стать достоянием всех.
Сегодня утром
коллега задал вопрос:
Часто в тестировании используют методы бек/форвард тест, иногда устраивают стресс тест, на хаотичных котировках, но в данном примере хотелось показать как смоделировать ситуацию, когда в алгоритме все хорошо, но по той или иной причине нашу заявку не исполнили.
Мой ответ (в 3-х частях, по мере внесения уточнений и подробностей) ему был следующий:
1. Все перечисленные «проблемы» решаются очень просто и успешно, если немного расширить само понятие «робот».
Добавьте надстройку, следящую за состоянием робота, за состоянием сети, инета, которая автоматически блокирует ненужные явления (задваивание ордеров на одном баре, например, или обрыв связи с сервером), и проблем не будет. Да, это выходит за рамки Lua (или того, на чем реализован робот). У меня такие сервисы реализованы на C#, опять же например. Итог: сам включается/выключается, «фильтрует базар» и поддерживает постоянное подключение, «постукивая» мне логами на почту или джаббер…
(тут следует уточняющий вопрос коллеги...)
2. ОК, расширю ответ: все неисполненные по каким-либо причинам ордера мой робот запоминает и при первой же возможности реализует. Сам! Я не влезаю в его работу, он сам решает проблему. Сам снимает, сам восстанавливает.
Главный закон моего робота: сигналы должны быть корректны и всегда исполнены на 100%.
(тут следует еще один уточняющий вопрос коллеги...)
3. Микаелян Саро, у меня робот ВСЕГДА исполняет сигнал. Для того, чтобы ордер был реализован, в моем роботе предусмотрен алгоритм сопровождения ордера в торговой системе. Он перемещает ордер, изменяет цену, объем — всё, что нужно, лишь бы выполнить главное — реализовать сигнал на 100%.
Ну, а то, что цена на рынке не совпадает с какой-то «расчетной», — это просто может стать результатом, что расчет, выполненный до сего момента, оказался неверным в настоящий момент, и его нужно скорректировать с учетом «момента».
Иллюстрация к моим ответам (в нотации IDEF0) — трехконтурная архитектура автономного торгового комплекса:
Как в тесте робот сможет прогнать такой вариант?
Часто подобная ситуация переворачивает результаты.
Допустим: Есть открытая. Диапазон достигнут, надо закрыть и развернуть.
Но тут же есть и в обратной стороне свечи добрать или отстопиться.
В итоге может получиться, что взята увеличенная поза по экстремуму и против себя.
Ну не на «тиках» же у Вас робот, который по «свечам» (сужу по описанию)?!!!
В том же МТ я решал проще — маркерами, которые просто прямо к заявке присасываются и сопровождают ордер-исполнение-закрытие на всём протяжении алгоритма робота… именно «РОБОТА»...
В иных — надо самому приблуду делать ))))
Секретик: «Маркер» — хорошее слово для заявки.
А когда у тебя используется 10+ инструментов сразу — тем более ))))
))))
Есть заявка — попала в данные свои очередной строкой.
Есть исполнение (добивка строки заявки в столбце сделок) — проверка на полноту.
Появилась новая заявка, когда прошлая строка не заполнена — значит прошлая не исполнена (ну или исполнена частично, если идёт сравнение объема).
Это же очень просто.
И потом, вопрос-то не в том, что нужно узнать состояние ордера и транзакции, когда ордер уже подан в систему, а как раз тогда, когда робот выработал сигнал, а ордер в систему не попадает, т.е. сигнал «пропал».
Есть иной вариант? если не на низкоуровневом пишешь?
Во всех приблудах есть отклик!!!!
Его и проверять!!
(при тестирование есть ли такое — не знаю, потому что в боевых всегда проверял, однако)
Ну, что ж, не мастер я, не мастер.
С ПРИБЛУДАМИ для программирования — просто (отклик) ...
Без приблуд на машинном — сразу надо закладывать отдельным блоком контроля исполнения.
(осталось)
Если крикнуть «Кто украл хомуты?» — ответ через пару секунд «ты-ты-ты» ...
Все всегда хотели при экскурсоводе крикнуть «Кому не спится в ночь глухую???» ..
Вот так ответ и получается.
Если крикнул одно, а получил иное — значит косяк.
Это и надо проверять ))))
Иначе можно получить полную чехарду.
Алгоритм рабочий, но за счет факта исполнения/неисполнения/частичного — он может просто привести к совсем иным результатам… а при бэктесте — только на тиках. ЧАСТО МОЖЕТ БЫТЬ ДВИГ В ОБЕ СТОРОНЫ ДАЖЕ НА МИНУТЕ, который попадает под алгоритм со всех сразу блоков принятия решения. Тут вопрос очередности блоков, однако, бектест не даст такого результата, какой вживую.
Могу четко сказать… одного из роботов я ещё лет 5 назад сажал на боевой счет и потом делал бектест на минутках (он не по барам работал)...
Итог плачевен.
Боевой + 120% за 6 мес… Тестовый — -40% на одном и том же периоде.
Это очень просто только в одном случае, в случае «лабораторных условий».
В реальной жизни, когда торгуется несколько сотен алгоритмов с разнообразными правилами выставления ордеров, с большим количеством ордеров и сделок по многим инструментам за торговую сессию, эта простая задача превращается в весьма сложную.
Вопрос в том, как избежать ошибок при тесте.
тесты, к сожалению, не способны при всех ухищрениях тестирующих, смоделировать те ситуации и ошибки, которые возникнут в реальной торговле ;)
да я же не спорю, тестируйте на здоровье. Но все в итоге будет зависеть от опыта. А его в тестах не найдете :)