Algorithmischer Handel für .NET und Python✦86+ Konnektoren · Börsen · Broker · Krypto✦S#.Designer · Backtest · optimieren · live gehen✦Eine Community von 31,458+ Tradern und Entwicklern✦Algorithmischer Handel für .NET und Python✦86+ Konnektoren · Börsen · Broker · Krypto✦S#.Designer · Backtest · optimieren · live gehen✦Eine Community von 31,458+ Tradern und Entwicklern✦
Хочу переделать OrderStates: слить два состояния Cancelled и Matched в
одно - Done. И добавить 3 extension метода: IsCancelled IsMatched
IsPartiallyFilled.
Возражения? Предложения?
Kommentare (10)
Anmelden oder Konto erstellen, Melden Sie sich an oder registrieren Sie sich, um einen Kommentar zu hinterlassen
Зачем это - Canceled и Matched четко отражали реальное состояние
заявки в квике - Снята и Исполена, это можно было анализировать и
предпринимать различные действия. А Done это все испротит. А методы
добавить - отличная идея, но зачем же состояния убирать?
а если необходима разная реакция на снятие заявки и ее исполенние? во
тя сейчас делаю арбитражера, мне именно такая реакция нужна..
Состояние частичное реализации можно сделать 3 способами
а) еще один State в дополнение к Matched и Canceled - тот же
OrderStates.PartialyMatched
б) метод расширения или свойсво IsPartialyMatched
в) тупо провреить Volume-Balance == Volume.
Еще раз повторюсь - текущие OrderStates полностью отражают реаьное
состояние заявки в системе. А Done - слабая информативность, тока в
любом случае придется проверить - а че именно то Done - сняли или
исполнили?
А вопрос - почему имеено Вы решили слить два состояния в одно?
Причина - отделить бизнес состояния от системных. Заявка по сути живет
следующий цикл: еще не принята, принята и активна, принята и не
активна. Это системные статусы, диктуемые биржей. Бизнес статусы - это
ничего вообще не исполнили, исполнили хоть что-то и слаба богу, мне
повезло я все исполнил.
К примеру, если использовать текущий подход, то можно получить заявку,
которая PartiallyMatched и Canceled одновременно. С точки зрения
человеческой логики - это абсурд. С точки зрения биржи - заявка
частично исполнилась, но мы ее сняли.
Ок, давайте Ваш случай. Где будет новая концепция не удобна?
Арбитражер.
Например робот выставляет заявку. Она
а) выполняется целиком - я вижу что она матчед, кидаю правую часть
б) Vol-Bal != Vol - я кидаю правую часть на vol-bal, и снимаю левую
часть
в) висит в стакане - трейдер это видит, РУКАИТ снимает ее, я вижу что
она Canceled, вибрысываю ее из коллекции для обработки заявок
вот тут то мне и надо смотреть кто Matched, кто частично исполнене, а
кто Canceled. И повторюсь еще раз - состояния Matched/Canceled
отражают реальное состояие заявки в торговом шлюзе.И кстати Matched/
Canceled - это самые что нинаесть бизнес состояни, а системные - этот
свойство Status.
кстати Вашу модель " Бизнес статусы - это
ничего вообще не исполнили, исполнили хоть что-то и слаба богу, мне
повезло я все исполнил." надо доплнить статусом - непонятно что
произошло, но заявку сняли от греха подальше :).
в принципе,Мтхаил, можно же еще одно свойсво ввести - бизнес
состояние. зачем ломать старое, которое широко используется?
Спокойствие, еще пока ничего не сломано. Поэтому и консультируюсь.
Если бы сломал - уже не до консультации.
order.IsMatched() будет короче, чем order.State ==
OrderStates.Matched
А вот тут мне кажется логика хромает. Кидать надо то что осталось,
и не важно, полностью исполнилось или нет.
И опять неправильный на мой взгляд подход. Завтра Вы сделаете,
чтобы робот сам снимал заявки по определенному условию и уже не
различите, кто снимал, человек или робот. Надо коллекцию делать из тех
заявок, что снимаются программно и что ручками. Если заявка снята
челом, то она будет отсутствовать в той коллекции.
Как плюс. Вы снимаете заявку. Вы какого статуса дожидаетесь? Если
только Canceled то не правильно. Надо два. А так будет только одна
проверка.
Опять же, из выше приведенной логики следует, что не так важно,
снята заявка или исполнилоась или активна все еще, а сколько
реализована контрактов.
Matched/Canceled - бизнес состояния. Я так и писал.
Робот и так будет снимать заявки по определенному условию, а так же их
может снять человек.
и я не могу знать кто снял - робот или человек.получается менятее шило
мыло - придется писать
if(order.State == OrderStates.Done && otder.IsCancel)
делаем одно (выяснем сколько контрактов таки прошло и на это колво
бросаем правую)
Wir verwenden Cookies, um die beste Erfahrung auf unserer Website zu gewährleisten. Durch die weitere Nutzung unserer Seite stimmen Sie der Verwendung von Cookies zu.
Kommentare (10)
Anmelden oder Konto erstellen, Melden Sie sich an oder registrieren Sie sich, um einen Kommentar zu hinterlassen
ай-ай, баба Яга против! это же нахрен летит ручная коррекция работы робота!
Зачем это - Canceled и Matched четко отражали реальное состояние заявки в квике - Снята и Исполена, это можно было анализировать и предпринимать различные действия. А Done это все испротит. А методы добавить - отличная идея, но зачем же состояния убирать?
Минусы текущего:
а если необходима разная реакция на снятие заявки и ее исполенние? во тя сейчас делаю арбитражера, мне именно такая реакция нужна.. Состояние частичное реализации можно сделать 3 способами
а) еще один State в дополнение к Matched и Canceled - тот же OrderStates.PartialyMatched б) метод расширения или свойсво IsPartialyMatched в) тупо провреить Volume-Balance == Volume.
Еще раз повторюсь - текущие OrderStates полностью отражают реаьное состояние заявки в системе. А Done - слабая информативность, тока в любом случае придется проверить - а че именно то Done - сняли или исполнили?
А вопрос - почему имеено Вы решили слить два состояния в одно?
Даже наверно не нужно пункт а) - а то придется в некторых случаях 3 статуса проверять :)
Причина - отделить бизнес состояния от системных. Заявка по сути живет следующий цикл: еще не принята, принята и активна, принята и не активна. Это системные статусы, диктуемые биржей. Бизнес статусы - это ничего вообще не исполнили, исполнили хоть что-то и слаба богу, мне повезло я все исполнил.
К примеру, если использовать текущий подход, то можно получить заявку, которая PartiallyMatched и Canceled одновременно. С точки зрения человеческой логики - это абсурд. С точки зрения биржи - заявка частично исполнилась, но мы ее сняли.
Ок, давайте Ваш случай. Где будет новая концепция не удобна?
Арбитражер. Например робот выставляет заявку. Она а) выполняется целиком - я вижу что она матчед, кидаю правую часть б) Vol-Bal != Vol - я кидаю правую часть на vol-bal, и снимаю левую часть в) висит в стакане - трейдер это видит, РУКАИТ снимает ее, я вижу что она Canceled, вибрысываю ее из коллекции для обработки заявок вот тут то мне и надо смотреть кто Matched, кто частично исполнене, а кто Canceled. И повторюсь еще раз - состояния Matched/Canceled отражают реальное состояие заявки в торговом шлюзе.И кстати Matched/ Canceled - это самые что нинаесть бизнес состояни, а системные - этот свойство Status. кстати Вашу модель " Бизнес статусы - это ничего вообще не исполнили, исполнили хоть что-то и слаба богу, мне повезло я все исполнил." надо доплнить статусом - непонятно что произошло, но заявку сняли от греха подальше :).
в принципе,Мтхаил, можно же еще одно свойсво ввести - бизнес состояние. зачем ломать старое, которое широко используется?
Спокойствие, еще пока ничего не сломано. Поэтому и консультируюсь. Если бы сломал - уже не до консультации.
Робот и так будет снимать заявки по определенному условию, а так же их может снять человек. и я не могу знать кто снял - робот или человек.получается менятее шило мыло - придется писать
if(order.State == OrderStates.Done && otder.IsCancel) делаем одно (выяснем сколько контрактов таки прошло и на это колво бросаем правую)
if( order.State == OrderStates.Done && otder.IsMatched)
делаем другое (бросаем правую чтобы перекрыто все контракты из левой)
if( order.State == OrderStates.Done && otder.IsPartialyMatched)
снова определяем сколько контрактов таки прошло?
а если часть заявки прошла, а потом ее сняли? какой статус будет?
Не надо так. order.IsCanceled() достаточно
order.IsMatched()
order.State == Done order.IsPartiallyMatched() = true