Что-то не очень понятна проблема. Есть методы получения баланса по бумагам, контрактам. Причем для разных типов расчетов. Все что они делают - это передают выдают данные, которые транслирует брокер. Сам терминал ничего не знает про ваши активы. Чем они не угодили?
Правда, в большинстве случаев, скрипт ведет свою позицию, и общая позиция на балансе ему не интересна и даже вредна. Ведь разные скрипты и человек могут вести торговлю одновременно. Один в лонг, другой в шорт - баланс 0, а позиции есть.
Нет. значение же не true, зачем с ним сравнивать. Зада же посмотреть, что в таблице. 4 - цикла, значит там 4 - записи
Лучше выводить не в сообщения, а в лог файл. Но раз через сообщения, то можно так:
Код
local t
for i=0,getNumberOf ("futures_client_limits")-1 do
t = {}
for k, v in pairs(getItem("futures_client_limits",i)) do
t[#t+1] = tostring(k)..' = '..tostring(v)
end
message('i: '..tostring(i+1)..' : '..table.concat(t, '; '))
end
Если это действительно принятие решения в реальном времени, то тогда и блок анализа должен работать с потоком данным (с заданным периодом квантования времени). Т.е. лучше всего в самом скрипте и организовать. А если снаружи, то это либо база данных куда будет записываться слепок данных в каждый квант времени (т.е. много данных), либо необходимо успевать анализировать каждый пакет данных и тогда можно сделать на socket или другим способом межпроцессорного взаимодействия.
Для накопления уже проще. Все записывать с заданной периодичностью, с отметкой точки времени, чтобы данные не смешивались. А уже куда записывать - менее важно, хоть и существенно.
Изначально разбивать не надо. Это же арифметическая операция (правда можно кеширование сделать, если память есть).
цена 127 - это целое(127/10)*10 = 120 цена 127 стала 120, т.е. период квантования = 10. Значит все числа из диапазона 120-129 становятся 120. А значит и их объем будет для числа 120.
А как получить объемы по ценам 123 или 134? Если у Вас задача суммировать обемы сделок по каждой цене, то тогда это более простая задача - просто суммировать объемы с одной и той же ценой.
t ] {} ....
t[123] = (t[123] or 0) + deal.qty
t[134] = (t[134] or 0) + deal.qty
И получите таблицу со всеми объемами, где ключ - это цена, а значение - это объем.
Что касается нефти, то я, обычно, такие числа привожу к целому, умножая на 10 в степени разрядности дробной части. А потом уже провожу манипуляции.
Загрузка в 12% - это не значит, что одно ядро все занимает. Чтобы однозначно сказать, необходимо открыть монитор ресурсов и посмотреть подробную картину для каждого ядра.
При любой установке соединения с сервером необходимо "ждать" момента когда соединение есть и пропущенные данные получены. Отследить установку соединения - не проблема. А вот подгрузку данных - уже приходится контролировать некие параметры. Для примера разность времени сервера и времени последнего полученного пакета. Пока пакеты не "догонят время", стоит подождать.
Правда по наблюдениям за процедурой старта терминала видно, что сначала отрисовываются окна, потом устанавливается соединение. Поэтому если скрипт просто подождет установки соединения, то графики, скорее всего, уже есть.
Статус стоп-заявки - это всего лишь индикатор того в каком состоянии заявка на сервере брокера. Исполнилась - значит исполнилось условие. Далее идет подача команды на установку лимитного ордера по указанным параметрам. Если команда не пройдет шлюз, то можно проверить это через бит 10 и 11 флагов стоп-заявки. Если же лимитный ордер был установлен, то у стоп-ордера будет заполнено поле linkedorder Номер заявки в торговои? системе, зарегистрированнои? по наступлению условия стоп-цены. По нему и можно найти лимитный ордер в таблице orders и проверить уже его статус, предпринять какие-то действия.
Вопрос целесообразности подписки на колбек. Если - это необходимо для получения цены сделки внутри бара, то это не лучшая идея, т.к. этот колбек медленный и будут пропуски.А если это для того, чтобы узнать, что пришел новый бар, то не проще ли запомнить прошлый Size и сравнить с новым. Когда придет тогда и делать что-то. А так колбек будет дергаться много раз, ради одного события.
Состояние заявки можно получить в колбеке OnOrder или найти в таблице ордеров запись по номеру ордера order_num (индекс записи можно запомнить).
Из таблицы сделок можно (а значит и из колбека OnTrade), конечно, но это на каждую сделку придется переходить в таблицу ордеров. Если ордер большой, то это уже может быть накладно. Колбек OnOrder прямо вернет запись таблицы ордеров.
Владимир, заявки могут быть не на закрытие всей позиции.
Egor Denisov написал: Здравствуйте. Хочу у себя реализовать lua скрипт реализующий функцию трейлинг-стопа с защитным временем. Вопрос в следующем: как правильно поступить, чтобы получить ситуацию, когда цена инструмента делает прокол на несколько процентов и возвращается обратно в течение 1-2 секунд. На игровых серверах таких ситуаций может и не быть совсем. Как моделировать и тестировать такие ситуации?
На демо серверах такое как раз чаще встречается.
Что же касается вопроса, то не очень понятно, что необходимо сделать. Не подтягивать стоп если это прокол? Если так, что самое простое - это организовать таймер ожидания функции проверки изменения цены с прошлого опроса. Тогда у Вас проверка будет более большими квантами времени. Если непрерывно, то, условно, это будет раз в 100 млс. А так - раз в установленное время секунд, скажем раз в 1 сек.
Правда здесь есть вероятность того, что именно во время проверки это аномальное изменение и случится. Для этого можно организовать счетчик. Т.е. если такое случается больше чем 1 раз проверок, то это подтвержденное изменение. Для примера: Проверяем 1 - нет изменений. Счетчик 0. Проверяем 2 - есть изменение. Счетчик 1. Проверяем 3 - уже нет изменения. Счетчик сбрасывается в 0.
В результате изменение пропущено как ложное. Вот если в течении двух отсчетов изменение сохранится, то есть.
Он не поддерживает кодировку Win1251. Квик же в 2022 только ее понимает... Правда для ZeroBrane можно скрипт на том же lua для перекодировки при открытия файла настроить. Но это не лучший вариант. Часто файлы потом не открываются вообще.
Спасибо большое, я и не сомневался что для тех кто пишет на LUA в quik это будет очевидно. МОжет еще подскажете, как сделать чтобы он срабатывал переодически по времени?
По всей видимости, это был сарказм. Окружение терминала в рамках qlua не предоставляет методов по доступу к окну доступных скриптов lua.
Вариантов два: -- Разобраться с утечкой памяти. Это будет единственно правильным решением.\ -- Написать некий proxy-метод в библиотеке, который будет приводить к перезапуску основной логики. И дергать его по таймеру уже из скрипта lua или прямо организовать цикличность в запуска в самой библиотеке.
Правда есть еще вариант: написать скрипт, использующий w32.dll. Найти окно доступных скриптов, виртуально нажать кнопки остановки и запуска. Для примера, как это сделано в автологинах.
Берем тот же скрипт, приводим к универсальному виду:
Код
_G.message = _G.message or _G.print
_G.message('begin: '..tostring(os.clock()))
local t = {}
for i = 1,150000 do
t = os.time()
end
_G.message('end: '..tostring(os.clock())..', memory: '..tostring(collectgarbage("count")))
Да, разница с чистым lua есть, но не сказал бы, что это как-то мешает. Тем более, что накладные расходы при запуске скрипта в окружении терминала есть.
Что касается хранения таблиц, то, как правило, необходимы последние для расчета чего-то в скользящем окне. Остальное то зачем держать - вычистить, сборщик уберет со временем.
Если данные транслируются в ТТТ, то и getParamEx вернет их. Укажите корректный код класса и код инструмента. Можете увидеть их в информационном окне: правая клавиша в строке ТТТ - информация об инструменте.
Как уже правильно сказали выше, файл должен быть в бинарном представлении открыт.
Вот отрывок из книги создателя языка:
Lua принимает предкомпилированный код практически везде, где он допускает исходный код. В частности, loadfile и load принимают предкомпилированный код.
Мы можем написать упрощенную версию luac непосредственно на Lua:
Код
p = loadfile(arg[1])
f = io.open(arg[2], "wb")
f:write(string.dump(p))
f:close()
Основная функция здесь — это string.dump: она получает функцию Lua и возвращает ее предкомпилированный код как строку, правильно оформленную для ее обратной загрузки в Lua.
Т.к. в Квике теперь две версии lua, то необходимо запускать все в одной версии.
Если версия Квика 7, то там lua 5.1. А вот с ним уже не все так очевидно. Он, действительно, может не переварить номер из 19 символов. Поэтому, собственно, и был переход на lua 5.3. https://forum.quik.ru/forum10/topic5119/ Поэтому обновляйте версию.
Если тип number и предположительно целое, то достаточно такой конструкции
Код
if type(x) == "number" and (math.floor(x) == x) then
return _VERSION == "Lua 5.1" and string.format("%0.16g", x) or tostring(math.tointeger(x) or x)
end
Что же касается получения данных из таблиц Квика, то вызов getItem необходимо свести к минимуму. Один вызов на индекс и запомнить в переменной. Иначе большой расход памяти.
А зачем изменять два раза параметр? Одного раза достаточно. Что касается видеть - то нет. Это либо ошибка, либо разработчики не предполагают изменение вне настроек. Правда если Вы хотите изменять и в коде и в поле настроек, то это уже другая задача: необходимо как-то "сказать коду", что поле изменено в форме и не изменяй его.
Впрочем, Вы можете решить данную задачу используя две (три) переменные.
Одна - в структуре Settings. Вторая - прошлое используемое значение (чтобы понимать, что в форме его изменили). Ну и третья - рабочая, значение которой берется из прошлых двух.
Если это чисто внутренние данные, то может тогда и не хранить их в Settings. А если необходимо именно в них, то можно перед выходом из функции Init установить необходимое значение и оно будет использоваться в расчетах.
Правда возникнет неоднозначная ситуация - в окне ввода параметров будет отображаться то, что ввел пользователь, а расчет будет вестись от переопределенного значения. Но это уже вопрос к разработчикам - Settings явно кешируется и выдается в форме ввода из кеша, не учитывая, что параметры изменены в коде.
Возможно, но чтобы понять проблему необходимо видеть код функции inicfg.load.
Хотя, как правило, если нет уверенности, что данные корректны, то стоит проверять значения прежде чем их использовать. Как минимум убедиться что type(updateIni) == 'table'. Но это не решит проблемы загрузки(записи по указанному пути) файла через сеть.
Видимо, все же стоит обратиться на форум для того продукта, где этот скрипт используется. Поиск дает ответ, что это какая-то игра GTA. Это форум посвящен совсем другому продукту.
nikolz написал: Ну да, типа скрыть тот ужас, который нагородили в роботе, который сливает депозит, но за деньги заказчика. Чтобы не было мучительно стыдно за такой развод. Тогда обязательно.
В принципе да. Но покупать алгоритм - то еще занятие. Тем более, что они все давно исследованы вдоль и поперёк. Для примера, если кто не видел - https://oxfordstrat.com/rd-blog/
Проверьте, что запускаете в корректной версии. В последних версиях Квика две версии lua 5.3.5 и 5.4.1. Если не выбираете в версию при запуске, то выбирается по умолчанию из настроек.
Что значит зачем. Lua не имеет встроенной поддержки web soсket. Поэтому необходимы библиотеки (а не программы), чтобы сие действие стало доступно. Ссылки на сборки библиотек недавно обсуждались.
Если речь про срочный рынок, то цену активации необходимо задавать конкретным значением. Например, рассчитать как сдвиг стоп-цены на 100-200 шагов цены, помня о зависимости ГО от цены. Но, как уже обсуждалось, не факт, что проскальзывание будет меньше. Поэтому контролировать связанный лимитный ордер необходимо.
Также ситуацию когда стоп ордер исполнен, а лимитный ордер не установлен, тоже необходимо контролировать. При этом учитывать, что просто может долго приходить ответ об его установке, а не кидаться и закрывать позицию самому. А то в итоге выйдет уже не закрытие позиции.
Не на всех рынках есть понятие "По рынку". Если после активации ордера лимитный ордер не смог пройти контроль лимитов цен, достаточности средств, то он не будет зарегистрирован. Правда, статус стоп-ордера должен быть "исполнен" т.е. не активный и не снят. А вот биты 10 и 11 как раз могут говорить о причине проблемы.
Проще можно, но когда сервер начнет возвращать данные не в ожидаемом формате, то придется уже разбирать формат.
Если же для себя пишешь, то конечно, можно упрощать. Правда надо помнить, что 9 утра сегодня - это больше чем 22:00 вчера. Если же просто время сравнивать, то будет ошибка.