Ладно, с шортами можно принудительно решить проблему, вбив руками таблицу доступных элементов. Но вот то, что OnDepoLimit приходит только через несколько секунд после события у БКС, это вообще убивает всю работу скрипта. Я всегда из него брал подтверждение выставления заявки. Причем это только у БКС таки на VIP сервере, у остальных брокеров было норм. Кто-нибудь сталкивался с этим у БКС еще? Или может я зря квик обновил руками до последней версии?
Serge123 написал: Из аналогичных функций есть ещё getBuySellInfoEx CalcBuySell
Попробовал все, не помогло. Проблема глубже, от брокера приходит такая неверная информация в квик. Причем в окне выставления заявки отображаются тоже неверные значения по размеру доступной операции. А есть поля просто доступности шортов в каких-то таблицах или функциях? по getBuySellInfoEx не понял что за типы клиентов и где хомяки? Тип клиента. Возможные значения: «1» – «МЛ»; «2» – «МП»; «3» – «МОП»; «4» – «МД»
У трех брокеров всегда использовал getBuySellInfo(FIRM_ID,CLIENT_CODE,CLASS_CODE,SEC_CODE,price).can_sell для подсчета возможной позы. И там где не давали шортить can_sell = 0 выдавал. Но тут у БКС выяснилось, что эти значения не соответствуют реальности, и шортить не дают бумаги у которых can_sell не равон нулю. Есть ли в квике какая-то другая таблица с реальными значениями? Откуда еще можно узнать доступную позу?
Просим Вас прислать используемый Lua-скрипт. Также уточните, пожалуйста, к какому серверу подключаетесь?
К серверу брокера. Вроде решил проблему принудительным обновлением CreateDataSource перед самым началом торгов.
Код
if SEC_CODES['m15'][i] == 0 or SEC_CODES['m15'][i] == nil then
SEC_CODES['m15'][i] = CreateDataSource(SEC_CODES['class_codes'][i],SEC_CODES['sec_codes'][i],INTERVAL_M15)
end
--- обновление свечей утром перед стартом
if (dt.hour == 9 and dt.min == 59 and dt.sec < 20) then
SEC_CODES['m15'][i] = CreateDataSource(SEC_CODES['class_codes'][i],SEC_CODES['sec_codes'][i],INTERVAL_M15)
end
local m15d = SEC_CODES['m15'][i]
SEC_CODES['pre_m15'][i] = m15d:C(m15d:Size()-1)
Но вопрос остается открытым, можно ли так обновлять результат CreateDataSource? Не занимает ли это дополнительной памяти?
А что вам дает 1 мс, если рассинхрон с сервером брокера до 100 мс бывает? Тут как не синхронизируй часы ПК, синхронности с брокером не получишь. Даже если предположить, что это обойдем, то простая синхронизация времени ПК все равно будет не идеальна +-10 мс после синхронизации. Тут была тема про это, там все очень плохо на ПК в аппаратной части с этой точки зрения.
Функцию CreateDataSource можно использовать только внутри функций main() и callback. А что будет, если в Init первый вызов был? Чет не обращал раньше на это внимание и все работало.
param – необязательный параметр. Если параметр не задан, то заказываются данные на основании таблицы обезличенных сделок, если задан – данные по этому параметру.
А если брокер не дает поток обезличенных сделок или отключен в настройках? Тогда как работает?
Все было нормально, но после обновления до последней версии перестали приходить данные по CreateDataSource без последних параметров. Вернее приходит только значения из открытого графика. По остальным инструментам не приходят. Уже перепробовал отключать в настройках "Исходя из настроек открытых пользователем таблиц". Не помогло. Не могу понять, что изменилось то?
Эту штуку к квику прикрутить можно? Есть примеры такого? Круто было бы отказаться от извращений с вводом в таблицы квика. Еще хорошо бы умела графики рисовать и координаты клика мышкой по ним выдавать на событие.
Что толку от jit, если квик однопоточный и большая часть тормозов внутренняя при отображении и обработке, а не в lua. Радует, что 5,4 на 20% шустрее 5,3. LuaJIT мы в квике не дождемся.
При исполнении крупной айсберг заявки состоящей из 10 частей в 1000 лотов страшно тормозит квик, практически виснет. Пакеты почти перестают приниматься. Все таблицы виснут, кроме стакана, который немного шевелится, но запаздывает по времени. Если посмотреть в это время в мобильном квике другого брокера, то заявка давно исполнилась и цена ушла ниже минут 5 назад. Вы бы хотя бы таблицы в отдельные потоки сделали и прием данных в буфер.
nikolz, а смысл с подкреплением обучать, а не на исторических данных? это ж сколько времени надо? вы ее на потоке сделок обучаете в онлайн? вроде же не скальперская?
nikolz, чем бинарная лучше обычных? тем, что на домашнем компе можно обучать? Или слоев побольше можно запихать? Что-то я не слышал, чтоб они особо развивались. Там у них все тоже самое, как у обычных по структуре? Сверточные слои есть? Библиотеки хоть есть? А на обычной какие результаты были? Намного хуже? А градиентный бустинг, деревья пробовали? Ускоритель котов? Там как результаты? Говорят, нужно постоянно их дообучать на последних данных, тогда что-то полезное начинают показывать?
Како же тормозной этот SearchItems. Или это у меня комп уже старый. Чтоб проверить 100 цен на наличие в них заявок уходит около минуты. Есть альтернативные методы?
Serge123 написал: activation_time NUMBER Время активацииdatetime TABLE Дата и время
проще попробовать и в потоке сделок потом посмотреть время исполнения и в логах выставление заявки они могут висеть на сервере брокера до этого времени, а там уже от сервака брокера зависит, у Открытия вообще задержки по несколько секунд внутри дня бывают в "критические" дни, уж что там на открытии происходит страшно подумать
Короче, разобрался, перекинул эти функции в OnOrder Там хоть возвращает таблицу заявок, а не сделок. Можно отфильтровывать исполненные до вызова моей findNumOrderPrice. Но как и OnTrade тоже по несколько раз вызывается на одну сделку.
После получения всех сделок, информация о состоянии заявки, нам больше не нужна.
А как тогда информацию о исполнении заявки брать? Я всегда из флагов заявки брал. Таблица исполненных заявок всегда содержит информацию по всем исполненным заявкам. Как тогда узнать, что больше активных заявок по этой цене не осталось?
Пытаюсь найти оставшиеся заявки по текущей цене внутри OnTrade
Код
function findNumOrderPrice(ordtable, TRADE_CLASS_CODE, TRADE_SEC_CODE, fPrice)
function myFindPriceNum(C,S,F,P)
if (tostring(C) == tostring(TRADE_CLASS_CODE)) and (tostring(S) == tostring(TRADE_SEC_CODE)) and (bit.band(F, 0x1) ~= 0) and (tostring(P) == tostring(fPrice)) then
return true
end
return false
end
local norders = SearchItems(ordtable, 0, getNumberOf(ordtable)-1, myFindPriceNum, "class_code,sec_code,flags,price")
if (norders ~= nil) and (#norders > 0) then
myLog('norders='..tostring(#norders))
return #norders
end
return 0
end
Но, в таблице заявок к этому моменту не успевают обновится данные, даже флаги, что заявка исполнена. Как их принудительно перепроверить внутри этой функции? myLog('norders='..tostring(#norders)) возвращает количество в последней сделке, даже если там несколько заявок было и все они разом исполнились. Точно такой же код поиска нормально работает в main cо старыми долговисящими заявками
Где-то в квике сохраняется история ошибок выполнения скриптов, хотя бы последнего ввполнения? Или только в окне запуска скриптов можно увидеть? А после закрытия квика больше эту ошибку н.бю. посмотреть?
Недавно был удивлен, ставил айсберг примерно 1% от дневного оборота по акции кусочками по 100 лотов. До этого всегда думал, что если по этой же цене стоит кто-то еще за тобой, то между кусочками айсберга его пропустят вперед твоего очередного кусочка, при удовлетворении заявки. А тут кто-то крупный бахнул по рынку и мой айсберг почти полностью съел, но не весь, а тот чел так и остался за мной. Но самое удивительной, что в потоке обезличенных сделок эта сделка прошла одной строкой в несколько тысяч контрактов. Это как? Я вообще думал, что айсберги, как и стопы, хранятся на сервере брокера и отправляются на биржу по мере исполнения кусочков? Пусть даже это ММ шалит и убрал свою же заявку перед тем как бахнуть по моей. Но в потоке сделок должны же быть видны все кусочки айсберга?
Что нибудь изменилось за 4 года? Айсберг заявки также нужно на русском отправлять? Или можно на английском? В документации к луа квика поля таблицы заявок только на английском описаны.
В идеале нужно записывать данные в таблицу с индексом и сразу возвращать управление, всю обработку производить уже в main.
Это все хорошо, когда БА двигается медленно. Но если нам надо успеть выставить новую заявку за доли секунды после срабатывания предыдущей. Иначе можем нарваться на комиссию биржи. В main можно делать только медленные запросы на сервер, требующие ожидания ответа. Если смешать всё в main, то все станет медленным из-за ожидания ответов. Из-за этого еще может потребоваться делать задержки в main. И перенос в main требует держать глобальные переменные или таблицы в памяти. В разумных пределах выгоднее высокочастотное делать в OnTrade. И очередь из коллбеков НЕ может расти бесконечно, так как новые заявки не успевают выставиться. Самое главное, меня интересует, будет ли эта очередь выполнятся строго последовательно?
Функции обратного вызова обрабатываются в основном потоке терминала QUIK.
Я так понял, что они все ставятся в одну очередь на обработку независимо от функции? Или у каждой функции своя очередь или есть приоритет в обработке? И пока не выполнится предыдущая полностью, следующая не вызывается? Если я например в OnTrade создам заявку и она сразу выполнится, то меня новая OnTrade не прервет? И функция может выполнятся сколь угодно долго и даже задержки в ней можно ставить (но лучше так не делать)? Или лучше по возможности максимально все в main переносить?
if (tostring(C) == tostring(TRADE_CLASS_CODE)) and (tostring(S) == tostring(TRADE_SEC_CODE)) and (F & 0x1 ~= 0) and (tostring(P) == tostring(fPrice)) then
заработало вроде разрабы, вы бы проверили, это явно не нормальная ситуация с типами