QUIK (версия 7.0.1.5)

Страницы: Пред. 1 2 3 4 5 След.
RSS
QUIK (версия 7.0.1.5), function OnTrade(trade), трехкратный вызов на одно событие.
 
Sergey Gorokhov,
как я вам говорил уже неоднократно:
Проверьте на боевом сервере сами и убедитесь, что он ведёт себя точно так же. Вы это делали? В какой версии, по-вашему, это исправили?
Надо делать так, как надо. А как не надо - делать не надо.
 
Sergey Gorokhov,
В QUIK 7.0.4.10 на боевом сервере:

Скрытый текст

Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
 
Здравствуйте!
Информация получена, проблема изучается. Постараемся в ближайшее время дать ответ.
 
Цитата
Старатель написал:
Sergey Gorokhov  ,
В QUIK 7.0.4.10  на боевом сервере :

    Скрытый текст      
Код
   26.02 . 16   14 : 07 : 25.090  [OnOrder] order_num =  20003386909 ;  1 
 26.02 . 16   14 : 07 : 25.090  [OnOrder] order_num =  20003386909 ;  1 
 26.02 . 16   14 : 08 : 04.772  [OnTrade] trade_num =  1404415763 ; order_num =  20003386909 ;  1 
 26.02 . 16   14 : 08 : 04.772  [OnTrade] trade_num =  1404415763 ; order_num =  20003386909 ;  1 
 26.02 . 16   14 : 08 : 04.776  [OnOrder] order_num =  20003386909 ;  0 

 26.02 . 16   14 : 11 : 07.868  [OnTrade] trade_num =  1404423113 ; order_num =  20003517712 ;  1 
 26.02 . 16   14 : 11 : 07.868  [OnTrade] trade_num =  1404423113 ; order_num =  20003517712 ;  1 
 26.02 . 16   14 : 11 : 07.868  [OnOrder] order_num =  20003517712 ;  0 
 26.02 . 16   14 : 11 : 07.868  [OnOrder] order_num =  20003517712 ;  0   

В конце указан остаток (balance). Заявки выставлялись вручную, поэтому наличие дублей нельзя объяснить добавлением trans_id в последующих колбэках.
    Скрытый текст      
Код
   26.02 . 16   14 : 10 : 30.077  [OnStopOrder] order_num =  113318863 ; trans_id =  1024 . Активна
 26.02 . 16   14 : 10 : 33.131  [OnTrade] trade_num =  1404422578 ; order_num =  20003504311 ;  8 
 26.02 . 16   14 : 10 : 33.131  [OnTrade] trade_num =  1404422578 ; order_num =  20003504311 ;  8 
 26.02 . 16   14 : 10 : 33.131  [OnTrade] trade_num =  1404422578 ; order_num =  20003504311 ;  8 
 26.02 . 16   14 : 10 : 33.131  [OnOrder] order_num =  20003504311 ;  0 
 26.02 . 16   14 : 10 : 33.131  [OnOrder] order_num =  20003504311 ;  0 
 26.02 . 16   14 : 10 : 33.131  [OnOrder] order_num =  20003504311 ;  0 
 26.02 . 16   14 : 10 : 33.131  [OnStopOrder] order_num =  113318863 ; trans_id =  1024 . Выставлена заявка в ТС:  20003504311 
 26.02 . 16   14 : 10 : 33.131  [OnStopOrder] order_num =  113318863 ; trans_id =  1024 . Выставлена заявка в ТС:  20003504311   
Добрый день,
   
    По данному обращению мы диагностируем что заявки, отправляются     пользователям столько раз, сколько раз они менялись на сервере (под     изменением понимается, как изменение статуса, остатка, так и     установка UID, trans_id). При этом по факту заявки могут быть     отправлены сразу в последнем, актуальном, состоянии. Поэтому клиенты     видят многократный апдэйт одной и той же заявки без ее видимых     изменений. В одной из следующих версий серверного ПО QUIK мы     постараемся исправить эту ситуацию, чтобы не дублировать отправку     заявки в одном и том же состоянии несколько раз.
 
Цитата
Stanislav Tvorogov написал:
Поэтому клиенты     видят многократный апдэйт одной и той же заявки без ее видимых     изменений. В одной из следующих версий серверного ПО QUIK мы     постараемся исправить эту ситуацию, чтобы не дублировать отправку     заявки в одном и том же состоянии несколько раз.
Вы там чем занимаетесь?
Lbot3D
 
можно ли фильтровать колбек onTrade на основе поля trade_num?
Если исполнение заявки выполнилось за один раз, придет три onTrade с одинаковыми полями.
Если же исполнение заявки выполнилось, к примеру за два раза, то придет 3 onTrade с trade_num = 123456 и еще 3 onTrade с trade_num = 67890
все правильно?
 
Цитата
Валентин написал:
можно ли фильтровать колбек onTrade на основе поля trade_num?
Добрый день,

Да, Вы можете выполнять фильтрование по нужным Вам условиям.
Цитата
Если исполнение заявки выполнилось за один раз, придет три onTrade с одинаковыми полями.
Если  же исполнение заявки выполнилось, к примеру за два раза, то придет 3  onTrade с trade_num = 123456 и еще 3 onTrade с trade_num = 67890
все правильно?
Верно.
 
т.е. мне требуется собрать все ответы от колбека onTrade в одну кучу (в массив) и выкинуть ненужные. Собирать я планирую
trade_num
order_num
qty
price.
Никак не могу понять, как их выловить и для начала поместить в массив? Если можно простой пример на примере одной переменной
 
Цитата
Старатель пишет:  подстановка значения 0 или "" вместо nil там, где значения в принципе нет, приводит к неопределённому поведению программы. В программировании это недопустимо. А суть такова, что проставлять нужно только те параметры, которые заведомо имеют какое-то значение. Параметры, не имеющие значений должны быть nil . Тогда робот, получивший колбек, в котором, не проставлены интересующие его параметры, будет понимать, что нужно ждать следующего колбека.  В данной ситуации это выглядело бы так: При получении сделки с бижи, если сервр не успел проставить номер транзакции, то он так и отправляет сделку с trans_id=nil (а не 0 ). После, когда сервер будет отправлять следующий колбек, он уже проставит номер транзакции.
    Добрый день,
    Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам,     что реализация пожелания признана потенциально целесообразной. Если     по результатам дальнейшего анализа, включающего юридические аспекты,     анализ на непротиворечивость с общей политикой компании, никаких     возражений не возникнет, мы постараемся включить Ваше пожелание в     план доработок при выпуске одной из следующих версий нашего ПО.
 
_sk_,      Добрый день,
   
    Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам,     что реализация пожелания признана потенциально целесообразной. Если     по результатам дальнейшего анализа, включающего юридические аспекты,     анализ на непротиворечивость с общей политикой компании, никаких     возражений не возникнет, мы постараемся включить Ваше пожелание в     план доработок при выпуске одной из следующих версий нашего ПО.
 
Цитата
написал:
Старатель пишет:  подстановка значения 0 или "" вместо nil там, где значения в принципе нет, приводит к неопределённому поведению программы. В программировании это недопустимо. А суть такова, что проставлять нужно только те параметры, которые заведомо имеют какое-то значение. Параметры, не имеющие значений должны быть nil . Тогда робот, получивший колбек, в котором, не проставлены интересующие его параметры, будет понимать, что нужно ждать следующего колбека.  В данной ситуации это выглядело бы так: При получении сделки с бижи, если сервр не успел проставить номер транзакции, то он так и отправляет сделку с trans_id=nil (а не 0 ). После, когда сервер будет отправлять следующий колбек, он уже проставит номер транзакции.

проще и безопасней, в таком случае, передавать параметры в строковом типе и если параметра нет - ставить "" - т.е. ничего не ставить.
присваивая же "nil" в LUA. Может получится так, что сборщик мусора - совсем избавится от этого параметра (честно говоря, давно не проверял - но, уже писалось кажется об этом).
 
Цитата
тот самый написал:
проще и безопасней, в таком случае, передавать параметры в строковом типе и если параметра нет - ставить "" - т.е. ничего не ставить.
присваивая же "nil" в LUA. Может получится так, что сборщик мусора - совсем избавится от этого параметра (честно говоря, давно не проверял - но, уже писалось кажется об этом).
Не не не не. Старатель знает, что пишет. И сборщик мусора тут не при чём. Любая Lua-таблица может быть проиндексирована любым значением в качестве индекса (кроме nil). В результате вы получите nil в случае, если ключ в таблице отсутствует или значение ключа. Поэтому код
Код
function OnTrade(trade)
    message(tostring(trade.aadfadfafdaf), 1);
end
не затрагивает сборщик мусора и абсолютно безопасен, хоть и бессмысленен.
 
Специально для проверки коллбэков переделал программку SuperScalp, с текстом программы на Lua:
http://smart-lab.ru/blog/314812.php
И что вижу при прогоне Quik версии 7.2.0.45?
Милую картинку - три идентичных отклика OnTrade() и два OnOrder(), если не считать разницу в миллисекунды между ними.
Стабильность - признак мастерства ©
Lbot3D
 
Здравствуйте,
Цитата
XXM написал:
Милую картинку - три идентичных отклика OnTrade() и два OnOrder(), если не считать разницу в миллисекунды между ними.
Не вижу причин упрека, никто не говорил что в версии 7.2 в этом месте что-то менялось
Рекомендуем ознакомиться со списком изменений.
 
Просто добавьте в Инструкции к LUA Quik что OnTrade может несколько раз вызываться по такой причине и проблем не будет, а то час если не больше убит на поиск проблемы.
 
OnOrder*
 
Мдаа.. Давненько я такого не встречал. Обратная совместимость 0/10, очевидность 0/10, документация 2/10, шлангование и перекаты 10/10.

Этот тред длиной в два года достоин того, чтобы поместить его первой ссылкой в тех.документации арки и квика.
Я бы даже сказал, что он обязателен к прочтению теми, кто собирается погружаться. Как и множество других, чуть менее эпичных.

Спасибо всем участникам за то, что многим сэкономили время на исследование этого архитектурного кошмара.

---
ключевые слова для гугла: Алготрейдинг для начинающих. Quik роботы с чего начать. Скрипты Quik Lua. А то так и будешь ключи подавать.
 
Quik 8.2.0.78
14:52:55.674 Отправил бай SendMarketOrder(classCode, secCode, tool.AccountID, Operation.Buy, 10);
14:52:55.847 OnTransReply(): По транзакции №=12145255 Успешно выставлена заявка №=4755649620 По цене=0 Объёмом=10
14:52:55.976 Events_OnMoneyLimit(): Изменилась позиция по деньгам: CurrentBal=272991,13 OpenBal=294251,82 Locked=28176,41
14:52:55.978 Events_OnDepoLimit(): Изменилась позиция по бумагам: SBER CurrentBalance=0 AweragePositionPrice=0
14:52:56.581 Events_OnTrade(): OrderNum=4755649620 OrderPrice=0 trade.Price=258,43 TransID=12145255 TradeNum=3126631556 Quantity=10 flag=0 OrderQty=0 SystemRef= UID=152656
14:52:56.582 Events_OnTrade(): OrderNum=4755649620 OrderPrice=0 trade.Price=258,43 TransID=12145255 TradeNum=3126631556 Quantity=10 flag=0 OrderQty=0 SystemRef= UID=152656
14:52:56.583 Events_OnTrade(): OrderNum=4755649620 OrderPrice=0 trade.Price=258,43 TransID=12145255 TradeNum=3126631556 Quantity=10 flag=0 OrderQty=0 SystemRef= UID=152656
14:52:56.584 Events_OnOrder(): OrderNum = 4755649620 TransID = 0
14:52:56.585 Events_OnOrder(): OrderNum = 4755649620 TransID = 12145255

Вопросы:
1. Для версии 8.2 все также 3 колбека для OnTrade() и 2 для OnOrder() ... ничего не исправили ?
Не смог найти отличий в квитанциях полученных в OnTrade, их три штуки ((( Я плохо искал ? судя по ответам разработчиков в этой ветке их не всегда 3 штуки может быть а от 1 до бесконечности ((((.

2. Как понять что полученная квитанция в  OnTrade окончательная и не будет больше меняться, т.е. я могу брать из неё данные и работать дальше?
вариант запоминать  TradeNum и обрабатывать заявки только с большим номером не проходит ((, т.к. при отправке 1000 лот, они разбиваются на части и там каша этот вариант не сработает....
Заранее спасибо.  

З.Ы. Пишу видео и выкладываю их на Ютуб. Программирование торговых роботов на языке С# через торговый терминал Quik. Если кому-то интересно присоединяйтесь буду искренне рад, любой помощи и подсказке.
ПлейЛист https://clck.ru/LRGZB

 
Здравствуйте, Сергей Привалов!
Цитата
1. Для версии 8.2 все также 3 колбека для OnTrade() и 2 для OnOrder() ... ничего не исправили ?
Не  смог найти отличий в квитанциях полученных в OnTrade, их три штуки ((( Я  плохо искал ? судя по ответам разработчиков в этой ветке их не всегда 3  штуки может быть а от 1 до бесконечности ((((.
Так как сделки являются обновляемыми, некоторые поля сделки могут меняться, в частности, заполняться некоторые поля (UID или TRANS_ID, например). В связи с этими изменениями OnTrade() и OnOrder() могут вызываться несколько раз, даже если визуально никакие поля не поменялись, так как не все поля структуры сделки видны через QLua.
Цитата
2. Как понять что полученная квитанция в  OnTrade окончательная и не  будет больше меняться, т.е. я могу брать из неё данные и работать  дальше?
вариант запоминать  TradeNum и обрабатывать заявки только с  большим номером не проходит ((, т.к. при отправке 1000 лот, они  разбиваются на части и там каша этот вариант не сработает....
К сожалению, понять точно последнее ли событие было обработано никак нельзя. Предугадать сколько будет обновлений или изменений параметров заявки нельзя.
QUIK clients support
 
Цитата
Эпик вин написал:
Мдаа.. Давненько я такого не встречал. Обратная совместимость 0/10, очевидность 0/10, документация 2/10, шлангование и перекаты 10/10.

Этот тред длиной в два года достоин того, чтобы поместить его первой ссылкой в тех.документации арки и квика.
Я бы даже сказал, что он обязателен к прочтению теми, кто собирается погружаться. Как и множество других, чуть менее эпичных.

Спасибо всем участникам за то, что многим сэкономили время на исследование этого архитектурного кошмара.
:lol:
Пятый пошел!

Цитата
Alexander Kopyatkevich написал:

...OnTrade() и OnOrder() могут вызываться несколько раз, даже если визуально никакие поля не поменялись, так как не все поля структуры сделки видны через QLua.
Вроде бы как-то обещали, что внесете порядковый номер обновления для каждой сущности, что было видно, что что-то поменялось.
Три года с тех пор прошло.
Lbot3D
 
Цитата
XXM написал:
Цитата
Эпик вин написал:
Мдаа.. Давненько я такого не встречал. Обратная совместимость 0/10, очевидность 0/10, документация 2/10, шлангование и перекаты 10/10.

Этот тред длиной в два года достоин того, чтобы поместить его первой ссылкой в тех.документации арки и квика.
Я бы даже сказал, что он обязателен к прочтению теми, кто собирается погружаться. Как и множество других, чуть менее эпичных.

Спасибо всем участникам за то, что многим сэкономили время на исследование этого архитектурного кошмара.
 
Пятый пошел!

Цитата
Alexander Kopyatkevich написал:

...OnTrade() и OnOrder() могут вызываться несколько раз, даже если визуально никакие поля не поменялись, так как не все поля структуры сделки видны через QLua.
Вроде бы как-то обещали, что внесете порядковый номер обновления для каждой сущности, что было видно, что что-то поменялось.
Три года с тех пор прошло.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
А зачем?

заведите в скрипте таблицу с полученными колбеками, по каждому пришедшему смотрите в ней уже имеющиеся и делайте свои выводы.

по вычислительной нагрузке это - ничто.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
s_mike@rambler.ru написал:
А зачем?
...
технически проблему эту я решил давно, знаю как обойти эти грабли.
Но они есть и приходят новые поколения, которые на них наступают.  
Lbot3D
 
 Отправляю заявку через скрипт Lua - 1 лот, использую свой TRANS_ID на транзакцию. Задача - если сделка произошла, значит надо отправить другую заявку. Т.е. мне нужен контроль исполнения заявки(сделка). Логи показывают, что сначала первой всегда откликается OnTransReply(), потом могут идти 3 вызова OnTrade() и 2 вызова OnOrder() в разной очерёдности. Логика контроля исполнения заявки(по сути приход сделки) была такая:
1) В OnOrder() если пришло изменение заявки, т.е. order.balance == 0 , то -> флаг is_nul = true.
2) В OnTrade() если trade.order_num == номеру моей заявки(получаю его через OnTransReply(), или в OnOrder() если пришла моя TRANS_ID если этот OnOrder() вызвался раньше OnTransReply()[мало ли?] , то -> флаг  is_trade = true.
3) Далее если if is_nul and is_trade then -> выставляем нужную заявку.

Я не рассчитывал на то, что колбэки могут отправляться по нескольку раз. Прочитал эту тему, понял, что могут и причём неограниченное число раз. Я не заморачивался и не тестил чем конкретно отличаются пришедшие в колбэках таблицы, но вижу, что OnOrder() где order.balance == 0 - 2 раза, и OnTrade() 3 раза и слава богу цена в нём одна и та же.

Вопросы:
1) Возможен ли вызов OnTransReply() на мою поданную заявку с моим TRANS_ID, с trans_reply.trans_id == 0, nil, "0", "" или же trans_reply.trans_id всегда содержит номер заявки? Этот номер заявки измениться не может?
2) OnTransReply() вызывается только один раз?
3) Возможен ли случай, когда сначала первой будет вызов OnOrder(), а потом уже вызов OnTransReply()? Вроде бы как-то один раз такое проскочило, когда скрипт вылетел с ошибкой исполнения. Но точно не помню, возможно было и так, даже скорее всего так, что был вызов только OnTrade(), а  OnTransReply() не вызвался, хотя по факту заявка выставилась. Из-за этого дублирую сохранение номера заявки не только в OnTransReply(), но и в OnOrder().
4) Могу ли я быть уверен, что имея самый первый OnOrder() c order.balance == 0, последующие OnOrder() не изменят значение  order.balance?
5) Могут ли приходить сначала OnTrade() без  trade.price, а потом с  trade.price? От этого зависит какие именно я могу использовать вызовы OnTrade(), т.е. нужно ли вообще проверять установлено ли в них поле  trade.price, или это поле заполнено ценой всегда и не меняется в следующих вызовах?
6) Могу ли я быть уверен, что имея самый первый OnTrade() с ценой исполнения trade.price, последующие OnOrder() не изменят значение trade.price?
7) Могу ли я с учётом своего алгоритма контроля исполнения использовать только самые первые вызовы OnOrder(), OnTrade(), OnTransReply(), отфильтровывая все последующие, где я фактически смотрю только на изменение баланса в заявке и жду появления сделки с номером заявки?
8) Может быть вообще как-то по другому изменить алгоритм контроля исполнения заявки(приход сделки)? Какой алгоритм контроля посоветуют разработчики с учётом всех этих многочисленных вызовов?

Все эти 0, nil, "0", "", которые могут прийти в trans_id в разных частных случаях в OnTrade() или в OnOrder() как я понял для меня не критичны, так как во всех колбэках я проверяю поля таблиц trans_id со своим номером транзакции TRANS_ID.
 
Alexander, Кроме своего TRANS_ID использовать просто нечего - ничто другое не гарантирует, что транзакция наша. Да и эта айдишка не гарантирует  - иногда туда прилетают нули или явно левые айдишки вроде 10, 25 и т.п. Контроль исполнения у меня только по OnTrade, не вижу никакого смысла в использовании ни OnTransReply, ни OnOrder. Никакой очерёдности здесь не соблюдается от слова совсем - задержки в приходе прерываний или изменения содержимого таблиц Квика могут составлять 10 минут и более. Я присобачил какую-то пародию на нечёткий поиск, и у меня точность идентификации заявки, по которой пришла сделка, близка к 100%, но здесь мне очень помогает блокировка: подача заявки запрещена, если предыдущая заявка по этому тикеру не исполнена или не снята. И не только колбэки могут отправляться по нескольку раз, но и заявки могут исполняться в несколько сделок, причём прерывания по ним приходят крест-накрест собачьим шагом. А вот цена в разных сделках по одной заявке может и отличаться. И, наконец, Вы НИ В ЧЁМ не можете быть уверены. В частности, самые первые вызовы OnTrade (остальное прерывания я не использую) могут содержать как раз бракованные данные, а самые вторые или самые третьи - правильные. А могут врать и все до единого. И проверка полей таблиц trans_id со своим номером транзакции не поможет. Я делаю подобную проверку только при снятии неисполненных или частично исполненных заявок, и далеко не всегда там правильные значения, а заявки я снимаю через три минуты активности.
 
Цитата
Владимир написал:
Alexander, Кроме своего TRANS_ID использовать просто нечего - ничто другое не гарантирует, что транзакция наша. Да и эта айдишка не гарантирует  - иногда туда прилетают нули или явно левые айдишки вроде 10, 25 и т.п. Контроль исполнения у меня только по OnTrade, не вижу никакого смысла в использовании ни OnTransReply, ни OnOrder. Никакой очерёдности здесь не соблюдается от слова совсем - задержки в приходе прерываний или изменения содержимого таблиц Квика могут составлять 10 минут и более. Я присобачил какую-то пародию на нечёткий поиск, и у меня точность идентификации заявки, по которой пришла сделка, близка к 100%, но здесь мне очень помогает блокировка: подача заявки запрещена, если предыдущая заявка по этому тикеру не исполнена или не снята. И не только колбэки могут отправляться по нескольку раз, но и заявки могут исполняться в несколько сделок, причём прерывания по ним приходят крест-накрест собачьим шагом. А вот цена в разных сделках по одной заявке может и отличаться. И, наконец, Вы НИ В ЧЁМ не можете быть уверены. В частности, самые первые вызовы OnTrade (остальное прерывания я не использую) могут содержать как раз бракованные данные, а самые вторые или самые третьи - правильные. А могут врать и все до единого. И проверка полей таблиц trans_id со своим номером транзакции не поможет. Я делаю подобную проверку только при снятии неисполненных или частично исполненных заявок, и далеко не всегда там правильные значения, а заявки я снимаю через три минуты активности.
Владимир, привет. Вот и в этой ветке встретились. Мне бы весь этот сыр-бор с колбеками свести к решению моей простой задачи. Мне собственно(во всяком случае пока) надо реализовать элементарный алгоритм. Покупка лота - 1 шт, т.е. автоматом отпадает возможность срабатывания только части заявки потому как 1 лот это 1 лот и его частично исполнить нельзя. Это намного упрощает задачу. Далее всё, что мне нужно это контроль исполнения этой заявки на покупку. Всё. Я должен быть на 100% быть уверен, что моя заявка исполнилась. И если исполнилась, то только тогда подаю следующую уже на продажу, так что тут такой же принцип блокировки - пока не сработает покупка - никакой продажи. На QPILE я это делал так - в цикле пробегал по таблице заявок в поиске своей заявки с номером который мне возвратила send_transaction() в своём результате, смотрел значения поля баланса когда станет равно нулю, как только оно стало равно нулю, то потом в цикле пробегал по таблице сделок и как только в ней появлялась запись с номером моей заявки, я считал что сделка исполнена. Не знаю насколько хорош такой алгоритм, но он работал всегда. Возможно, что достаточно было просто увидеть ноль на балансе в таблице заявок и плюнуть на таблицу сделок, не знаю. Или наоборот, может достаточно было бы и того что сделка появилась в таблице сделок. Но я для надёжности решил использовать и то и то. Перейдя на Lua сначала обрадовался, что есть колбэки и не надо бегать в цикле по таблицам в поиске нужного номера заявки, но не тут то было. С одной стороны всё просто. С другой стороны - куча вопросов. А есть ли гарантия? На данный момент меня интересует пока только одно, могу ли я использовать самый первый вызов OnOrder(), в котором на балансе появился ноль вместо единицы и отбросить все остальные вызовы? Могу ли я использовать только самый первый вызов OnTrade(), который мне показал, что в нём появился номер моей заявки, взять из него цену и быть уверенным, что эта цена не меняется в следующих вызовах, и что вообще есть ли гарантия, что эта цена будет в самом первом этом вызове, т.е. надо ли проверять что цена не ноль, а остальные вызовы отбросить?
Если так можно, то суть контроля исполнения оставляю ту же - приход нуля в балансе заявки и(AND) появление сделки. Открытым в принципе остаётся вопрос, а надо ли вообще делать 2 проверки или может быть достаточно только какой-то одной из них? Если вызовы колбэков идут вразнобой, может заменить AND на OR? Может вообще как-то изменить сам алгоритм контроля исполнения? Как? Как лучше?

PS. Разработчики накуралесили конечно знатно, оставив пользователям самим разбираться во всём, потому как много непоняток и нет однозначности. Не мешало бы самим этим разработчикам в документации привести хотя бы элементарный пример контроля исполнения заявки использую колбэки!
 
Alexander, Да, у меня тоже стояла (а на срочном рынке до сих пор стоит) заглушка 1 заявка - 1 лот, но это не так уж сильно упрощает задачу и не гарантирует на 100% исполнение. Там масса всяких неприятных нюансов. Бегать по таблицам я категорически не хочу, у меня торговля довольно агрессивная, а задержки при обновлении данных в таблицах могут составлять минуты. Блокировка ставится в момент подачи заявки в Квик и снимается либо в OnTrade, если она полностью исполнена, либо после снятия по таймеру. Кроме того, у меня заведено аж три стека, чтобы практически вся обработка выполнялась в потоке мейна, а в таблицу сделок не заглядываю вообще никогда. И я уже говорил, что самый первый вызов OnTrade вовсе не означает, что данные там правильные, и проверка цены на ноль тоже ничего не гарантирует. Я хотел когда-то обсудить как лучше и создать совместными усилиями библиотеку функций на Луа по подаче и контролю исполнения заявок, по организации диалога - в общем, всю техническую часть, не касающуюся алгоритмов торговли, но тут же прибежала распальцованная шушера и засрала ветку поросячьим визгом. После двух попыток я плюнул на это дело, и лучшим считаю то, что использую сам. А от разработчиков хочу только одного: чтобы они перестали плодить новые версии, пока система ещё хоть как-то работает.
 
Цитата
Alexander написал:
Я не рассчитывал на то, что колбэки могут отправляться по нескольку раз. Прочитал эту тему, понял, что могут и причём неограниченное число раз. Я не заморачивался и не тестил чем конкретно отличаются пришедшие в колбэках таблицы, но вижу, что OnOrder() где order.balance == 0 - 2 раза, и OnTrade() 3 раза и слава богу цена в нём одна и та же.

Вопросы:
1) Возможен ли вызов OnTransReply() на мою поданную заявку с моим TRANS_ID, с trans_reply.trans_id == 0, nil, "0", "" или же trans_reply.trans_id всегда содержит номер заявки? Этот номер заявки измениться не может?
2) OnTransReply() вызывается только один раз?
3) Возможен ли случай, когда сначала первой будет вызов OnOrder(), а потом уже вызов OnTransReply()? Вроде бы как-то один раз такое проскочило, когда скрипт вылетел с ошибкой исполнения. Но точно не помню, возможно было и так, даже скорее всего так, что был вызов только OnTrade(), а  OnTransReply() не вызвался, хотя по факту заявка выставилась. Из-за этого дублирую сохранение номера заявки не только в OnTransReply(), но и в OnOrder().
4) Могу ли я быть уверен, что имея самый первый OnOrder() c order.balance == 0, последующие OnOrder() не изменят значение  order.balance?
5) Могут ли приходить сначала OnTrade() без  trade.price, а потом с  trade.price? От этого зависит какие именно я могу использовать вызовы OnTrade(), т.е. нужно ли вообще проверять установлено ли в них поле  trade.price, или это поле заполнено ценой всегда и не меняется в следующих вызовах?
6) Могу ли я быть уверен, что имея самый первый OnTrade() с ценой исполнения trade.price, последующие OnOrder() не изменят значение trade.price?
7) Могу ли я с учётом своего алгоритма контроля исполнения использовать только самые первые вызовы OnOrder(), OnTrade(), OnTransReply(), отфильтровывая все последующие, где я фактически смотрю только на изменение баланса в заявке и жду появления сделки с номером заявки?
8) Может быть вообще как-то по другому изменить алгоритм контроля исполнения заявки(приход сделки)? Какой алгоритм контроля посоветуют разработчики с учётом всех этих многочисленных вызовов?

Все эти 0, nil, "0", "", которые могут прийти в trans_id в разных частных случаях в OnTrade() или в OnOrder() как я понял для меня не критичны, так как во всех колбэках я проверяю поля таблиц trans_id со своим номером транзакции TRANS_ID
1)  OnTransReply - это колбек об отправке транзакции. Т е транзакция ушла с сервера брокера и попала на сервер биржи.
единственный параметр в ней который не изменится это trans_id.
------------------------
Его надо использовать для идентификации транзакций.
Все остальное может бить или не быть в зависимости от того как обрабатывается эта транзакция на сервере биржи.
---------------------
2) Надо делать программу так, чтобы число срабатывания колбеков не влияло на результат.
Для этого надо не считать число срабатываний, а реагировать на события о которых сообщается в информации принятой колбеком.
Если новая информация не изменяет состояния Вашего робота (конечного автомата) то какая разница, сколько раз сработает колбек.
состояние не изменится.
------------------
3) OnOrder может приходить много-много раз. Например Вы поставили лимитную заявку 100 лотов , а встречные заявки  содержат по 1 лоту.
Сколько раз сработает OnOrder? Правильно... много.
Поэтому читайте ответ 2)
-------------------
4) см 2)
5)см 2)
6) см 2)
7) нет
8) ДА
------------------
 
Здравствуйте.

Цитата
Alexander написал:
Вопросы:1) Возможен ли вызов OnTransReply() на мою поданную заявку с моим TRANS_ID, с trans_reply.trans_id == 0, nil, "0", "" или же trans_reply.trans_id всегда содержит номер заявки? Этот номер заявки измениться не может?2) OnTransReply() вызывается только один раз?3) Возможен ли случай, когда сначала первой будет вызов OnOrder(), а потом уже вызов OnTransReply()? Вроде бы как-то один раз такое проскочило, когда скрипт вылетел с ошибкой исполнения. Но точно не помню, возможно было и так, даже скорее всего так, что был вызов только OnTrade(), а  OnTransReply() не вызвался, хотя по факту заявка выставилась. Из-за этого дублирую сохранение номера заявки не только в OnTransReply(), но и в OnOrder().4) Могу ли я быть уверен, что имея самый первый OnOrder() c order.balance == 0, последующие OnOrder() не изменят значение  order.balance?5) Могут ли приходить сначала OnTrade() без  trade.price, а потом с  trade.price? От этого зависит какие именно я могу использовать вызовы OnTrade(), т.е. нужно ли вообще проверять установлено ли в них поле  trade.price, или это поле заполнено ценой всегда и не меняется в следующих вызовах?6) Могу ли я быть уверен, что имея самый первый OnTrade() с ценой исполнения trade.price, последующие OnOrder() не изменят значение trade.price? 7) Могу ли я с учётом своего алгоритма контроля исполнения использовать только самые первые вызовы OnOrder(), OnTrade(), OnTransReply(), отфильтровывая все последующие, где я фактически смотрю только на изменение баланса в заявке и жду появления сделки с номером заявки?8) Может быть вообще как-то по другому изменить алгоритм контроля исполнения заявки(приход сделки)? Какой алгоритм контроля посоветуют разработчики с учётом всех этих многочисленных вызовов?
1. Всегда содержит trans_id и этот параметр не меняется.
2. Да.
3. Возможен. В связи с тем, что различные биржи предоставляют интерфейс подключения к своим системам по разным протоколам и разным схемам, в некоторых заявки и сделки доставляются разными не синхронизированными потоками, также не нужно исключать факт потери пакетов. Таким образом возможны ситуации, когда первым будет вызван OnOrder().
4. Если пришёл OnOrder с balance = 0 - значит заявка исполнилась полностью, т.е. сделки на всё количество в заявке, и что дальше происходит с balance в OnOrder по данной заявке не важно.
5. Да, данный параметр не меняется в последующих вызовах.
6. Да, данный параметр не меняется в последующих вызовах. Если речь об одной заявке и только об одной сделке по ней - то цена не должна меняться. Если же по заявке может быть заключено больше одной сделки - то у каждой сделки может быть своя цена, которая может быть выгоднее цены в заявке.
7. Нет.
8. К сожалению, посоветовать какой-либо алгоритм контроля исполнения заявки мы не можем. Как уже верно заметил выше nikolz - общая рекомендация для сделок и заявок - не "затачивать" алгоритм на определенный порядок вызова OnOrder/OnTrade и их количество.  
 
Цитата
Alexey Danin написал:
Здравствуйте.

Цитата
Alexander написал:
Вопросы:1) Возможен ли вызов OnTransReply() на мою поданную заявку с моим TRANS_ID, с trans_reply.trans_id == 0, nil, "0", "" или же trans_reply.trans_id всегда содержит номер заявки? Этот номер заявки измениться не может?2) OnTransReply() вызывается только один раз?3) Возможен ли случай, когда сначала первой будет вызов OnOrder(), а потом уже вызов OnTransReply()? Вроде бы как-то один раз такое проскочило, когда скрипт вылетел с ошибкой исполнения. Но точно не помню, возможно было и так, даже скорее всего так, что был вызов только OnTrade(), а  OnTransReply() не вызвался, хотя по факту заявка выставилась. Из-за этого дублирую сохранение номера заявки не только в OnTransReply(), но и в OnOrder().4) Могу ли я быть уверен, что имея самый первый OnOrder() c order.balance == 0, последующие OnOrder() не изменят значение  order.balance?5) Могут ли приходить сначала OnTrade() без  trade.price, а потом с  trade.price? От этого зависит какие именно я могу использовать вызовы OnTrade(), т.е. нужно ли вообще проверять установлено ли в них поле  trade.price, или это поле заполнено ценой всегда и не меняется в следующих вызовах?6) Могу ли я быть уверен, что имея самый первый OnTrade() с ценой исполнения trade.price, последующие OnOrder() не изменят значение trade.price? 7) Могу ли я с учётом своего алгоритма контроля исполнения использовать только самые первые вызовы OnOrder(), OnTrade(), OnTransReply(), отфильтровывая все последующие, где я фактически смотрю только на изменение баланса в заявке и жду появления сделки с номером заявки?8) Может быть вообще как-то по другому изменить алгоритм контроля исполнения заявки(приход сделки)? Какой алгоритм контроля посоветуют разработчики с учётом всех этих многочисленных вызовов?
1. Всегда содержит trans_id и этот параметр не меняется.
2. Да.
3. Возможен. В связи с тем, что различные биржи предоставляют интерфейс подключения к своим системам по разным протоколам и разным схемам, в некоторых заявки и сделки доставляются разными не синхронизированными потоками, также не нужно исключать факт потери пакетов. Таким образом возможны ситуации, когда первым будет вызван OnOrder().
4. Если пришёл OnOrder с balance = 0 - значит заявка исполнилась полностью, т.е. сделки на всё количество в заявке, и что дальше происходит с balance в OnOrder по данной заявке не важно.
5. Да, данный параметр не меняется в последующих вызовах.
6. Да, данный параметр не меняется в последующих вызовах. Если речь об одной заявке и только об одной сделке по ней - то цена не должна меняться. Если же по заявке может быть заключено больше одной сделки - то у каждой сделки может быть своя цена, которая может быть выгоднее цены в заявке.
7. Нет.
8. К сожалению, посоветовать какой-либо алгоритм контроля исполнения заявки мы не можем. Как уже верно заметил выше nikolz - общая рекомендация для сделок и заявок - не "затачивать" алгоритм на определенный порядок вызова OnOrder/OnTrade и их количество.  
Хорошо. По пункту 8 вы не советуете конкретный алгоритм. Но это в общем случае не советуете, поскольку вариантов может быть много. Но я спрашиваю конкретно для своего наипростейшего случая, что описал выше. Например - покупка 1 лота. Нужен контроль того, что покупка 1-го лота 100% прошла и только тогда подавать на продажу того же 1-го лота. Какой алгоритм контроля применить посоветует техподдержка? Уж куда проще то? Мой алгоритм подойдёт? Или можно его упростить, например - вообще не использовать OnTrade()? Достаточно проверить OnOrder() где баланс = 0? Сейчас использую и то и то. А надо ли? Вроде работает.
 
Цитата
Владимир написал:
И я уже говорил, что самый первый вызов OnTrade вовсе не означает, что данные там правильные, и проверка цены на ноль тоже ничего не гарантирует.
Если оно так, то получается что просто нет возможности в квике сделать контроль исполнения заявки. А раз так, то получается, что всё остальное просто не имеет никакого смысла. Какой смысл писать робота или ещё чего, если нельзя осуществить контроль исполнения заявки? Нет уверенности в исполнении - дальше ничего делать нельзя!!! Либо есть возможность со 100%-ной уверенностью программно определить, что заявка исполнена, либо вообще тогда надо закрывать все обсуждения, да и вообще тогда теряет смысл программирования на этом самом Lua.
 
Короче, ещё спрошу так. Отправил заявку например на покупку 1 лота. В OnTrade() проверил, что  order.trans_id == моему TRANS_ID и order.order_num == TRANSACTION_COMPLETED[tostring(order.trans_id)], короче отфильтровал по своей заявке и проверил что order.balance == 0. Этого достаточно для контроля исполнения заявки?
 
Alexander, Почему нельзя? Можно. Только вот мой личный "рекорд" в ожидании подтверждения исполнения заявки составляет семнадцать с половиной минут, и это наверняка не предел. А робот, тем не менее, написан и работает "вот прям ща". Не со 100%-ной уверенностью, поменьше, но работает. И написан он с головы до пят на чистейшем Lua. :smile:

Нет, Вы не путайте заявку и сделку. Если заявка именно в 1 лот, то остаток гарантированно в нуле, и сам факт прихода OnTrade говорит о том, что заявка исполнена (обычно в трёх экземплярах). По большому счёту, гарантирует идентификацию только совпадение trans_id, поскольку order_num формируется не нами, и я его, как правило, вообще не знаю. А вот для контроля исполнения заявки лично у меня заведён специальный стек активных заявок, из которого полностью исполненные или снятые заявки удаляются уже по таймеру.
 
Цитата
Владимир написал:
Alexander, Почему нельзя? Можно. Только вот мой личный "рекорд" в ожидании подтверждения исполнения заявки составляет семнадцать с половиной минут, и это наверняка не предел. А робот, тем не менее, написан и работает "вот прям ща". Не со 100%-ной уверенностью, поменьше, но работает. И написан он с головы до пят на чистейшем Lua. ::

Нет, Вы не путайте заявку и сделку. Если заявка именно в 1 лот, то остаток гарантированно в нуле, и сам факт прихода OnTrade говорит о том, что заявка исполнена (обычно в трёх экземплярах). По большому счёту, гарантирует идентификацию только совпадение trans_id, поскольку order_num формируется не нами, и я его, как правило, вообще не знаю. А вот для контроля исполнения заявки лично у меня заведён специальный стек активных заявок, из которого полностью исполненные или снятые заявки удаляются уже по таймеру.
Контроль исполнения заявки, которая например в вашем стеке у которой 1 лот контролируется по balanse == 0?
 
Alexander, У меня заявки могут исполняться за произвольное количество сделок, так что любой приход OnTrade, не отфильтрованный как дубль, корректирует оставшееся количество лотов в заявке, а сам элемент стека удаляется уже в другом месте - либо по снятию, либо действительно по нулевому остатку.
 
У меня сейчас для заявки в 1 лот алгоритм такой. OnOrder(): если для моей заявки balance == 0 - ставлю один флаг. Пришёл OnTrade()[сделка прошла значит] с моей заявкой - ставлю другой флаг и беру цену из него и в переменную. Функция контроля иcполнения ждёт появления обоих флагов, если пришли, то цену беру из переменной. Так же внутри OnOrder()  и OnTrade() использую ещё свои флаги для того чтобы отбрасывать ненужные их вызовы - по сути OnOrder() как только пришёл в балансе ноль - ставлю флаг, следующий вызов проверяет этот флаг и если он есть, то игнорирую вызов, так же и в OnTrade(), как пришла моя сделка - ставлю флаг, чтобы отсекать другие возможные её вызовы. Вот и думаю, может просто достаточно только OnOrder() и брать из неё цену исполнения и достаточно?
 
Цитата
Владимир написал:
Alexander, У меня заявки могут исполняться за произвольное количество сделок, так что любой приход OnTrade, не отфильтрованный как дубль, корректирует оставшееся количество лотов в заявке, а сам элемент стека удаляется уже в другом месте - либо по снятию, либо действительно по нулевому остатку.
Ваш алгоритм в принцине понял. В конечном итоге полное исполнение всё равно идёт по балансу в OnOrder().
 
А я вот решил почему-то ещё и ждать прихода самой сделки, использую OnTrade(). Может это и не надо. Что скажут разработчики? Нужен ли двойной контроль?
 
Alexander, Я вообще не использую OnOrder. Никогда не использовал. :smile: Только OnTrade.
 
Цитата
Alexander написал:
Цитата
Alexey Danin написал:
Здравствуйте.
Но я спрашиваю конкретно для своего наипростейшего случая, что описал выше. Например - покупка 1 лота. Нужен контроль того, что покупка 1-го лота 100% прошла и только тогда подавать на продажу того же 1-го лота. Какой алгоритм контроля применить посоветует техподдержка? Уж куда проще то? Мой алгоритм подойдёт? Или можно его упростить, например - вообще не использовать OnTrade()? Достаточно проверить OnOrder() где баланс = 0? Сейчас использую и то и то. А надо ли? Вроде работает.
Объясняю как я делаю это.
--------------------------------
Например, циклический тест  выставления и снятия заявки.
Это тест подобен Вашей задаче.
Отличие лишь в том, что я контролировал снятие заявки, а Вы контролируете исполнение заявки.
Но алгоритм , описанный ниже решает обе задачи.
================
Результат тестирования алгоритма,
показал его безошибочную работу при случайном выставлении и снятии заявки по 200 инструментам.
За 4 часа теста на демо сервере выставлено и снято 200 тысяч заявок без единой ошибки.
==================
Алгоритм:
------------------------------
Преамбула:
Робот - это конечный автомат, который изменяет свое состояние в зависимости от внешних сигналов и своей цели.
Источником внешних сигналов являются колбеки.
------------------------
В моем роботе задействованы все колбеки, описанные в документации библиотеки QLua
Заверяю Вас, что лишних колбеков нет.
Вы можете не использовать какие-либо колбеки, но это подобно тому, что у человека отключить какой-либо орган.
-------------------------------
Если Вы колбек выкидываете, то ваш робот не видит многих событий и просто зависнет в один прекрасный момент.
===========
Если инструмент, по которому я хотел бы выставить заявку активен
,т е произошло событие по данному инструменту ( сделка, изменение заявки),
то проверяем по таблице заявок есть ли активная и  по таблице транзакций есть ли активная   по этому инструменту.
----------------------
Если есть активная , то новая заявка не выставляется, иначе выставляется.
-----------------
В более продвинутом алгоритме выполняется анализ актуальности текущего состояния , но это уже другая задача.
 
 
nikolz, Какой-то клинический бред.

1. Я уже говорил, что Ваше выставление и снятие 200 тысяч заявок за 4 часа иллюстрирует лишь полную беспомощность алгоритма торговли - у нормальных людей заявки ставятся не для того, чтобы их снимать, а для того, чтобы они исполнялись. Мои заявки, например, исполняются в 90% случаев и более.

2. В моем роботе задействован ОДИН колбек, и он называется OnTrade. Есть, правда, ещё и OnStop, но только для того, чтобы не было потери данных, поскольку при нажатии кнопки "Остановить" скрипт теряет управление - Антон в своё время подробно рассказывал, почему. Так что заверяю Вас, что ВСЕ колбеки лишние, кроме этих двух, да и то второй нужен только для компенсации глюка в софте Квика. Это рудиментарные органы и должны быть вырезаны к чертям собачьим для блага человека. :smile:

3. Я выбросил (точнее, даже не задействовал) все остальные колбеки, перенёс все расчёты в поток main (избавился от этого маразма с потоками), и давно уже забыл, что такое зависание Квика, хотя ранее доводилось видеть и internal error, и unknown hard error, и даже general protection error. А вот если Вы подключите всю эту дребедень, тогда Ваш робот вообще ничего не увидит и просто зависнет в один прекрасный момент. И таких прекрасных моментов будет ой как много!

4. Я вообще не контролирую исполнение заявки: пришёл OnTrade - значит, исполняется, а на нет и суда нет. И в таблицу заявок лезу крайне редко, только для снятия активных заявок. И снятие заявки не контролирую: послал KILL_ORDER - и пусть канает! И это ЕДИНСТВЕННАЯЯ таблица, в которую я вообще лезу (не считая ТТТ, конечно).

5. Выставление заявки НИКАК не зависит от того, активна ли предыдущая. Вернее, у меня-то как раз зависит, но это алгоритм такой: новая заявка не выставляется, если не исполнена или не снята предыдущая по этому тикеру и даже если курс не сдвинулся относительно предыдущей сделки на какую-то величину, а вот выставляется она не потому, что нет активных заявок, а по целой куче других критериев, чтобы сделка была не абы какой, а прибыльной. А вот Борис, например, выставляет целый веер заявок, многие из которых остаются активными в течение достаточно длительного времени.

Короче, "смотри пункт первый". :smile:  
 
Здравствуйте.

Цитата
Alexander написал:
Какой алгоритм контроля применить посоветует техподдержка? Уж куда проще то? Мой алгоритм подойдёт? Или можно его упростить, например - вообще не использовать OnTrade()? Достаточно проверить OnOrder() где баланс = 0? Сейчас использую и то и то. А надо ли?
Вы можете протестировать Ваши алгоритмы, проанализировать и выбрать более эффективный для Вас. Протестировать можно на учебном сервере QUIK Junior.
 
Цитата
Alexey Danin написал:
Здравствуйте.

Цитата
Alexander написал:
Какой алгоритм контроля применить посоветует техподдержка? Уж куда проще то? Мой алгоритм подойдёт? Или можно его упростить, например - вообще не использовать OnTrade()? Достаточно проверить OnOrder() где баланс = 0? Сейчас использую и то и то. А надо ли?
Вы можете протестировать Ваши алгоритмы, проанализировать и выбрать более эффективный для Вас. Протестировать можно на учебном сервере  QUIK Junior .
О как! Интересно. Даже не знал, что есть такая возможность. Учтём.
 
Цитата
nikolz написал:
Цитата
Alexander написал:
 
Цитата
Alexey Danin  написал:
Здравствуйте.
Но я спрашиваю конкретно для своего наипростейшего случая, что описал выше. Например - покупка 1 лота. Нужен контроль того, что покупка 1-го лота 100% прошла и только тогда подавать на продажу того же 1-го лота. Какой алгоритм контроля применить посоветует техподдержка? Уж куда проще то? Мой алгоритм подойдёт? Или можно его упростить, например - вообще не использовать OnTrade()? Достаточно проверить OnOrder() где баланс = 0? Сейчас использую и то и то. А надо ли? Вроде работает.
Объясняю как я делаю это.
--------------------------------
Например, циклический тест  выставления и снятия заявки.
Это тест подобен Вашей задаче.
Отличие лишь в том, что я контролировал снятие заявки, а Вы контролируете исполнение заявки.
Но алгоритм , описанный ниже решает обе задачи.
================
Результат тестирования алгоритма,
показал его безошибочную работу при случайном выставлении и снятии заявки по 200 инструментам.
За 4 часа теста на демо сервере выставлено и снято 200 тысяч заявок без единой ошибки.
==================
Алгоритм:
------------------------------
Преамбула:
Робот - это конечный автомат, который изменяет свое состояние в зависимости от внешних сигналов и своей цели.
Источником внешних сигналов являются колбеки.
------------------------
В моем роботе задействованы все колбеки, описанные в документации библиотеки QLua
Заверяю Вас, что лишних колбеков нет.
Вы можете не использовать какие-либо колбеки, но это подобно тому, что у человека отключить какой-либо орган.
-------------------------------
Если Вы колбек выкидываете, то ваш робот не видит многих событий и просто зависнет в один прекрасный момент.
===========
Если инструмент, по которому я хотел бы выставить заявку активен
,т е произошло событие по данному инструменту ( сделка, изменение заявки),
то проверяем по таблице заявок есть ли активная и  по таблице транзакций есть ли активная   по этому инструменту.
----------------------
Если есть активная , то новая заявка не выставляется, иначе выставляется.
-----------------
В более продвинутом алгоритме выполняется анализ актуальности текущего состояния , но это уже другая задача.
Ну я собственно использую большинство колбэков, и для контроля исполнения использую и OnOrder() и OnTrade() впаре чисто для повышения надёжности. Хотя уверен, что и OnTrade() было бы вполне достаточно. Работает и ладно.
 
Цитата
Владимир написал:
1. Я уже говорил, что Ваше выставление и снятие 200 тысяч заявок за 4 часа иллюстрирует лишь полную беспомощность алгоритма торговли - у нормальных людей заявки ставятся не для того, чтобы их снимать, а для того, чтобы они исполнялись. Мои заявки, например, исполняются в 90% случаев и более.
Владимир, а может быть nikolz специально ставит в стакан заявки и потом их снимает не для того, чтобы исполнить, а может быть для того, чтобы сбить с толку других роботов, заставить их сработать, или нет, мало ли?
 
Вот ещё хочу тут спросить старожилов по такому поводу. Скрипт на Lua сначала делает продажу акций Лукойл по рынку в шорт 10 шт через sendTransaction() при этом естественно ставлю TYPE="M", PRICE="0".
Транзакция проходит, заявка исполнилась нормально. Следующая транзакция на покупку фьючерса "LKZ2", т.е. LKOH-12.22 в количестве 1шт так же по рынку, где в sendTransaction() установлено так же TYPE="M", PRICE="0". Но при этом транзакция с ошибкой: Ошибка создания заявки. [GW][332] "Нехватка средств по лимитам клиента." Пытаюсь купить данный фьючерс вручную в квике, установив галочку в окне ввода заявки "Рыночная" - результат опять та же самая ошибка!
В результате фьючерс купил таки вручную, указав цену на покупку из стакана равную лучшей цене продажи. Транзакция прошла без ошибок и заявка тут же исполнилась. Да мог бы поставить цену покупки и выше чем лучшая цена продажи на несколько пунктов, это я знаю, и заявка ушла бы так по лучшей рыночной цене.
Но вопрос: почему sendTransaction() работает на покупку/продажу акций по рынку с значениями TYPE="M", PRICE="0", а на  покупку/продажу фьючерса с значениями TYPE="M", PRICE="0" выдаёт ошибку: "Нехватка средств по лимитам клиента." и я вынужден ставить цену хуже рынка, чтобы заявка ушла по рынку? Заявка то в конечном итоге прошла, значит средств достаточно!
 
Цитата
Alexander написал:
Вот ещё хочу тут спросить старожилов по такому поводу. Скрипт на Lua сначала делает продажу акций Лукойл по рынку в шорт 10 шт через sendTransaction() при этом естественно ставлю TYPE="M", PRICE="0".
Транзакция проходит, заявка исполнилась нормально. Следующая транзакция на покупку фьючерса "LKZ2", т.е. LKOH-12.22 в количестве 1шт так же по рынку, где в sendTransaction() установлено так же TYPE="M", PRICE="0". Но при этом транзакция с ошибкой: Ошибка создания заявки. [GW][332] "Нехватка средств по лимитам клиента." Пытаюсь купить данный фьючерс вручную в квике, установив галочку в окне ввода заявки "Рыночная" - результат опять та же самая ошибка!
В результате фьючерс купил таки вручную, указав цену на покупку из стакана равную лучшей цене продажи. Транзакция прошла без ошибок и заявка тут же исполнилась. Да мог бы поставить цену покупки и выше чем лучшая цена продажи на несколько пунктов, это я знаю, и заявка ушла бы так по лучшей рыночной цене.
Но вопрос: почему sendTransaction() работает на покупку/продажу акций по рынку с значениями TYPE="M", PRICE="0", а на  покупку/продажу фьючерса с значениями TYPE="M", PRICE="0" выдаёт ошибку: "Нехватка средств по лимитам клиента." и я вынужден ставить цену хуже рынка, чтобы заявка ушла по рынку? Заявка то в конечном итоге прошла, значит средств достаточно!
читайте
Раздел 5. Торговые операции клиента. Руководство пользователя QUIK.
там все написано.
 
Цитата
Alexander написал:
Вот ещё хочу тут спросить старожилов по такому поводу. Скрипт на Lua сначала делает продажу акций Лукойл по рынку в шорт 10 шт через sendTransaction() при этом естественно ставлю TYPE="M", PRICE="0".
Транзакция проходит, заявка исполнилась нормально. Следующая транзакция на покупку фьючерса "LKZ2", т.е. LKOH-12.22 в количестве 1шт так же по рынку, где в sendTransaction() установлено так же TYPE="M", PRICE="0". Но при этом транзакция с ошибкой: Ошибка создания заявки. [GW][332] "Нехватка средств по лимитам клиента." Пытаюсь купить данный фьючерс вручную в квике, установив галочку в окне ввода заявки "Рыночная" - результат опять та же самая ошибка!
В результате фьючерс купил таки вручную, указав цену на покупку из стакана равную лучшей цене продажи. Транзакция прошла без ошибок и заявка тут же исполнилась. Да мог бы поставить цену покупки и выше чем лучшая цена продажи на несколько пунктов, это я знаю, и заявка ушла бы так по лучшей рыночной цене.
Но вопрос: почему sendTransaction() работает на покупку/продажу акций по рынку с значениями TYPE="M", PRICE="0", а на  покупку/продажу фьючерса с значениями TYPE="M", PRICE="0" выдаёт ошибку: "Нехватка средств по лимитам клиента." и я вынужден ставить цену хуже рынка, чтобы заявка ушла по рынку? Заявка то в конечном итоге прошла, значит средств достаточно!
Рыночных заявок на срочном рынке нет, на самом деле. Брокер Они отправит их по верхней|нижней границе допустимого ценового диапазона. Так происходит, потому что размер ГО, блокируемого под сделку, зависит от цены сделки. И чем дальше цена от цены последнего клиринга, там ГО будет выше. Хотя реальная сделка и будет не так далеко, но расчет ГО у брокера будет по цене ордера. Так что на сделку в 200 пунктах от цены клиринга может и хватает, а вот уже на сделку в 2000 пунктах - нет. Но такое происходит, если торговать на границе доступных средств. Когда средств достаточно, то и "по рынку" пройдет сделка.
 
Alexander, Ха-ха-ха! Нет, я допускаю, что nikolz настолько тупой, чтобы пытаться изображать из себя кукловода, но вот в то, что ЕГО робот специально ставит в стакан заявки, чтобы сбить с толку других роботов, верить категорически отказываюсь - по той же причине. Нормальным скриптам (моему, например) весь этот суходроч глубоко по барабану - он вообще не знает, что такое стакан. И по рынку я, кстати, тоже никогда не торговал.
 
Цитата
Nikolay написал:
Цитата
Alexander написал:
Вот ещё хочу тут спросить старожилов по такому поводу. Скрипт на Lua сначала делает продажу акций Лукойл по рынку в шорт 10 шт через sendTransaction() при этом естественно ставлю TYPE="M", PRICE="0".
Транзакция проходит, заявка исполнилась нормально. Следующая транзакция на покупку фьючерса "LKZ2", т.е. LKOH-12.22 в количестве 1шт так же по рынку, где в sendTransaction() установлено так же TYPE="M", PRICE="0". Но при этом транзакция с ошибкой: Ошибка создания заявки. [GW][332] "Нехватка средств по лимитам клиента." Пытаюсь купить данный фьючерс вручную в квике, установив галочку в окне ввода заявки "Рыночная" - результат опять та же самая ошибка!
В результате фьючерс купил таки вручную, указав цену на покупку из стакана равную лучшей цене продажи. Транзакция прошла без ошибок и заявка тут же исполнилась. Да мог бы поставить цену покупки и выше чем лучшая цена продажи на несколько пунктов, это я знаю, и заявка ушла бы так по лучшей рыночной цене.
Но вопрос: почему sendTransaction() работает на покупку/продажу акций по рынку с значениями TYPE="M", PRICE="0", а на  покупку/продажу фьючерса с значениями TYPE="M", PRICE="0" выдаёт ошибку: "Нехватка средств по лимитам клиента." и я вынужден ставить цену хуже рынка, чтобы заявка ушла по рынку? Заявка то в конечном итоге прошла, значит средств достаточно!
Рыночных заявок на срочном рынке нет, на самом деле. Брокер Они отправит их по верхней|нижней границе допустимого ценового диапазона. Так происходит, потому что размер ГО, блокируемого под сделку, зависит от цены сделки. И чем дальше цена от цены последнего клиринга, там ГО будет выше. Хотя реальная сделка и будет не так далеко, но расчет ГО у брокера будет по цене ордера. Так что на сделку в 200 пунктах от цены клиринга может и хватает, а вот уже на сделку в 2000 пунктах - нет. Но такое происходит, если торговать на границе доступных средств. Когда средств достаточно, то и "по рынку" пройдет сделка.
Ну как бы есть или нет на срочном рынке заявки по рынку это вопрос отдельный, потому как например фьючерсы на юань у меня спокойно скрипт покупал и продавал по рынку по 1 шт(от шёлка мышкой, так просто для ускорения исполнения писал, чтобы не вводить вручную). Я так же склонялся и склоняюсь к тому, что ГО разное на разных ценах и по границам Min/Max оно скорее всего превысило - об этом подумал сразу. Но, что интересно, раньше вроде бы, если мне память не изменяет было такое, да - вручную ввод заявки по фьючерсу на одной цене - ГО показывает одно, на другой цене дальше к границе стакана - ГО другое. Но сейчас хоть на какой цене ни щёлкай - ГО одно и то же показывает в окне ввода заявки, оно точно соответствует тому ГО, что в ТТТ для инструмента. Поэтому и решил здесь спросить.
Страницы: Пред. 1 2 3 4 5 След.
Читают тему
Наверх