Algorithmischer Handel für .NET und Python✦86+ Konnektoren · Börsen · Broker · Krypto✦S#.Designer · Backtest · optimieren · live gehen✦Eine Community von 31,459+ 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,459+ Tradern und Entwicklern✦
Да я как то так ,по мсдну разбирался. и по примерам. я пару статей по
3.5 прочитал, начинал с него. но думаю в этом плане 3.5 и 4 - разницы
никакой нет.
Так а зачем тогда Вы while чиклы пишите? Торговые алгоритмы опираются
на события. Думаю не спроста такие системы как ВетЛаб и Квант
предоставляют именно событийную модель работы. Понятно, что внутри иет
логика последовательная ввиде условий и циклов. Но отправная точна
всегда событие: закончился бар, начался новый, цена превысила, заявка
изменилась и т.д. Может все же идти по пути именно событий? Его до нас
уже протоптали.
Суть в том что все эти танцы с бубном лишь для того, чтобы сварганить
инструмент, в ктором трейдер будет робота РИСОВАТЬ, а рисовать он
может только в виде детерминированых блок-схем. трейдеру будет трудно
рассказать, как пользовать события, почему вмсето того, чтобы на
снятие заявки получить ответ - успешно или неспешн опрошло снятие, он
должен слушать событие, да и мне - разработчику намного удобнее было
бы написать
if(trader.CancelOrder(order))
{
действия при успешном снятии
else
{
при неуспешном
чем отменять заявку, а потом в событии получть заявку, выснять что
именно это за заявка, и какие действия были с ней в прошлом, и что
делать в будущем..
так же намного удобнее проверять заявку
if( status.Done && PartiallyMatched)
чем слушать событие.
а если заявок много, кторые надо проверять? тут уже в событийно
модели начинаются неудобства :)
Вообще конечно, как мне кажется, много пользы прнес бы смешаный режим,
т.к. выстаявлять заявки удобно в асинхронном - и там уже слушать
событии, а вот снимать например лучше в синхроноом - там сразу ясно -
снял или не снял.А так придется блокировки ставить пояле запроса на
снятии, в событии снимать - ну вы сами понимаетет прелести
ассинхронного программирования. :) Извините что так сумбурно :)
P.S. События жутко удобная вещь для написания всяческого рода
индикаторов, тут они выше всяких похвал.
так GuaranteeCancelOrder вроде решение проблемы.А насчет обертки -
буду думать. у меня счас приоритет арбитражер. :) Ежели обертку
синхринизирвоаную намучу - дам вам знать - может сгодится в
стокшарпе :)
Я сейчас отложил воркфлоу немножко,пишу арбитражера по человечески, на
событиях. Но обязательно вернусть к этому вопросу.
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 (12)
Anmelden oder Konto erstellen, Melden Sie sich an oder registrieren Sie sich, um einen Kommentar zu hinterlassen
OrdersChanged пока не придет State Done
мутить блокировки с помощью ManualSetEvent?
Да, видимо придется как в примере SampleConsole раз у вас шаг за шагом... Надо бы глянуть на этот новый WF. Рекомендуете статью для начинающего?
Да я как то так ,по мсдну разбирался. и по примерам. я пару статей по 3.5 прочитал, начинал с него. но думаю в этом плане 3.5 и 4 - разницы никакой нет.
Вы пишите, что там state режима нет. Так что есть.
в смысле state режима? там есть Flowchart
Так а зачем тогда Вы while чиклы пишите? Торговые алгоритмы опираются на события. Думаю не спроста такие системы как ВетЛаб и Квант предоставляют именно событийную модель работы. Понятно, что внутри иет логика последовательная ввиде условий и циклов. Но отправная точна всегда событие: закончился бар, начался новый, цена превысила, заявка изменилась и т.д. Может все же идти по пути именно событий? Его до нас уже протоптали.
Писал развернутый ответ - и тырнет крякнул.
Суть в том что все эти танцы с бубном лишь для того, чтобы сварганить инструмент, в ктором трейдер будет робота РИСОВАТЬ, а рисовать он может только в виде детерминированых блок-схем. трейдеру будет трудно рассказать, как пользовать события, почему вмсето того, чтобы на снятие заявки получить ответ - успешно или неспешн опрошло снятие, он должен слушать событие, да и мне - разработчику намного удобнее было бы написать
if(trader.CancelOrder(order)) { действия при успешном снятии
else { при неуспешном
чем отменять заявку, а потом в событии получть заявку, выснять что именно это за заявка, и какие действия были с ней в прошлом, и что делать в будущем..
так же намного удобнее проверять заявку
if( status.Done && PartiallyMatched) чем слушать событие.
а если заявок много, кторые надо проверять? тут уже в событийно модели начинаются неудобства :)
Вообще конечно, как мне кажется, много пользы прнес бы смешаный режим, т.к. выстаявлять заявки удобно в асинхронном - и там уже слушать событии, а вот снимать например лучше в синхроноом - там сразу ясно - снял или не снял.А так придется блокировки ставить пояле запроса на снятии, в событии снимать - ну вы сами понимаетет прелести ассинхронного программирования. :) Извините что так сумбурно :)
P.S. События жутко удобная вещь для написания всяческого рода индикаторов, тут они выше всяких похвал.
Напрашивается обертка над ITrader (по аналогии с SyncTrader). Может сами сделаете? У меня сейчас приоритеты другие.
так GuaranteeCancelOrder вроде решение проблемы.А насчет обертки - буду думать. у меня счас приоритет арбитражер. :) Ежели обертку синхринизирвоаную намучу - дам вам знать - может сгодится в стокшарпе :)
Насколько я понял, у Вас таких мест уже несколько:
Так что Вам по любому такое надо. Иначе код будете загромождать While Wait и т.д.
Я сейчас отложил воркфлоу немножко,пишу арбитражера по человечески, на событиях. Но обязательно вернусть к этому вопросу.