Mikhail Sukhov
|
Date: 7/8/2010
Так а зачем тогда Вы while чиклы пишите? Торговые алгоритмы опираются на события. Думаю не спроста такие системы как ВетЛаб и Квант предоставляют именно событийную модель работы. Понятно, что внутри иет логика последовательная ввиде условий и циклов. Но отправная точна всегда событие: закончился бар, начался новый, цена превысила, заявка изменилась и т.д. Может все же идти по пути именно событий? Его до нас уже протоптали.
|
Tauler
|
Date: 7/9/2010
|
|
|
|
Писал развернутый ответ - и тырнет крякнул.
Суть в том что все эти танцы с бубном лишь для того, чтобы сварганить инструмент, в ктором трейдер будет робота РИСОВАТЬ, а рисовать он может только в виде детерминированых блок-схем. трейдеру будет трудно рассказать, как пользовать события, почему вмсето того, чтобы на снятие заявки получить ответ - успешно или неспешн опрошло снятие, он должен слушать событие, да и мне - разработчику намного удобнее было бы написать
if(trader.CancelOrder(order)) { действия при успешном снятии
else { при неуспешном
чем отменять заявку, а потом в событии получть заявку, выснять что именно это за заявка, и какие действия были с ней в прошлом, и что делать в будущем..
так же намного удобнее проверять заявку
if( status.Done && PartiallyMatched) чем слушать событие.
а если заявок много, кторые надо проверять? тут уже в событийно модели начинаются неудобства :)
Вообще конечно, как мне кажется, много пользы прнес бы смешаный режим, т.к. выстаявлять заявки удобно в асинхронном - и там уже слушать событии, а вот снимать например лучше в синхроноом - там сразу ясно - снял или не снял.А так придется блокировки ставить пояле запроса на снятии, в событии снимать - ну вы сами понимаетет прелести ассинхронного программирования. :) Извините что так сумбурно :)
P.S. События жутко удобная вещь для написания всяческого рода индикаторов, тут они выше всяких похвал.
|