Описание полей в методе on_trans_reply

Страницы: 1
RSS
Описание полей в методе on_trans_reply
 
Когда снимаю заявку на срочном рынке (да и на фондовом), мне прилетает сообщение в callback on_trans_reply. В нем есть поле flags, смысл которого мне непонятен и документации я что то не нашел. Также есть поле cancalled_uid, которое всегда одно и то же. В чем его смысл? Оно прилетает в on_order
 
Добрый день.

Параметр flags для функции onTransReply содержит следующие значения:
- бит 20 (0x21) Служебная транзакция
- бит 21 (0x22) Транзакция на выставление заявки

Параметр canceled_uid для функции onOrder содержит идентификатор пользователя, снявшего заявку.

Все параметры и их описания вы сможете найти в мануале Интерпретатор языка Lua (ссылка кликабельна).
 
Похоже, документация не соответствует реальности. Во-первых, что за странные цифры в скобках - (0x21) и (0x22)?
А во-вторых, я записывал в лог значения полей в OnTransReply, и в flags вижу такие значения:
0x260001 - при выставлении заявки на продажу.
0x240001 - при выставлении заявки на покупку и снятии любой заявки.
Отличаются они в 22 бите. Но установлен этот бит только при выставлении заявки на продажу, не на покупку.
 
Похоже опять несоответствие в справке?

Для флагов транзакций напечатано "бит 20 (0x21) и бит 21 (0x22)".

Математические маски битов 20 и 21 — 0x100000 и 0x200000;
по самой справке нельзя однозначно установить, где именно опечатка?

справка QLua - версия руководства 13.1;


И еще одно. Как проверять флаг? Для корректного целого flags заявки или собственной сделки:

Код
local is_sell = bit.test(flags, 2)             -- 2: номер бита
local is_sell_54 = (flags & 0x4) ~= 0   -- 0x4: маска, Lua 5.4.1


bit.band(flags, 0x4) возвращает 0 или 4, а не 0 или 1.
Проверять нужно через ~= 0. Кроме того, в Lua число 0 считается истинным, поэтому if bit.band(...) then — опасная проверка.
Почему Так?
 
Поскольку поддержка отмалчивается, проведу разбор самостоятельно, для себя и таких как я (хотя и слабо разбираюсь в этом), а что делать?

1. Опечатка в тексте руководства ARQA Technologies очевидна, авторы справки перепутали номера битов и шестнадцатеричные (HEX) маски. Авторы опечатались в HEX-записи. Они хотели написать бит 20 (маска 0x100000) и бит 21 (маска 0x200000). Но почему то написали 0x21 и 0x22?
Видимо механически скопировали номера битов, забыв перевести их в степени двойки и ошибочно записав номера битов 20 и 21 как 0x20 / 0x21, а затем сдвинули индексы?
Доверять HEX-значениям 0x21 и 0x22 из этой справки нельзя — они полностью неверны.

2. Ловушка Истины или почему 0 в Lua — это true? Это главная концептуальная ловушка для программистов, переходящих на Lua с языков Си, C++ или Python.
В отличие от Си/Python, где 0 — это false, любое другое число — это true.
В Lua (всех версий), логическим ложным значением (false) признаются исключительно два ключевых слова: false и nil. Всё остальное, включая число 0, пустую строку "" и пустую таблицу {}, интерпретатором Lua всегда признается истиной (true)!

Так как в терминал QUIK v11+ при работе на чистом Lua 5.4.1, встроенная библиотека bit (которая была внешней .dll в старых версиях) является устаревшей. Появилась возможность использовать родные поразрядные Си-операторы Lua 5.4.1, которые работают на уровне процессора и не тратят время на вызовы функций.
Собствено на этом можно и закончить. Хотя про это много уже писалось повторюсь. Вот золотой стандарт проверки флагов, который гарантирует отсутствие ложных срабатываний (как памятка):

Вариант 1. Проверка через родной оператор Lua 5.4.1 (&) — Рекомендуемый HFT-выбор. Оператор & (побитовое И) возвращает значение маски (например, 4) или 0. Проверяем строго через ~= 0:
-- Проверяем Бит №2 заявки/сделки (маска 2^2 = 4, то есть 0x4)
-- На Мосбирже: flags & 0x4 ~= 0 означает "Сделка на ПРОДАЖУ"
local is_sell = (flags & 0x4) ~= 0
if is_sell then
   -- Блок выполнится строго если бит присутствует (результат операции равен 4)
end

Вариант 2. Проверка через встроенную функцию bit.test в старых скриптах. Если используете функцию bit.test, она сама под капотом делает сравнение и возвращает чистый булев тип (true или false). Здесь оператор ~= 0 не нужен:
-- В функцию передается не маска, а чистый НОМЕР БИТА (начиная с 0)
local is_sell = bit.test(flags, 2) -- Возвращает true или false
if is_sell then
   -- Код безопасен, так как is_sell — это честный boolean
end
 
Цитата
VPM написал:
Поскольку поддержка отмалчивается, проведу разбор самостоятельно, для себя и таких как я (хотя и слабо разбираюсь в этом), а что делать?

1. Опечатка в тексте руководства ARQA Technologies очевидна, авторы справки перепутали номера битов и шестнадцатеричные (HEX) маски. Авторы опечатались в HEX-записи. Они хотели написать бит 20 (маска 0x100000) и бит 21 (маска 0x200000). Но почему то написали 0x21 и 0x22?
Видимо механически скопировали номера битов, забыв перевести их в степени двойки и ошибочно записав номера битов 20 и 21 как 0x20 / 0x21, а затем сдвинули индексы?
Доверять HEX-значениям 0x21 и 0x22 из этой справки нельзя — они полностью неверны.

2. Ловушка Истины или почему 0 в Lua — это true? Это главная концептуальная ловушка для программистов, переходящих на Lua с языков Си, C++ или Python.
В отличие от Си/Python, где 0 — это false, любое другое число — это true.
В Lua (всех версий), логическим ложным значением (false) признаются исключительно два ключевых слова: false и nil. Всё остальное, включая число 0, пустую строку "" и пустую таблицу {}, интерпретатором Lua всегда признается истиной (true)!

Так как в терминал QUIK v11+ при работе на чистом Lua 5.4.1, встроенная библиотека bit (которая была внешней .dll в старых версиях) является устаревшей. Появилась возможность использовать родные поразрядные Си-операторы Lua 5.4.1, которые работают на уровне процессора и не тратят время на вызовы функций.
Собствено на этом можно и закончить. Хотя про это много уже писалось повторюсь. Вот золотой стандарт проверки флагов, который гарантирует отсутствие ложных срабатываний (как памятка):

Вариант 1. Проверка через родной оператор Lua 5.4.1 (&) — Рекомендуемый HFT-выбор. Оператор & (побитовое И) возвращает значение маски (например, 4) или 0. Проверяем строго через ~= 0:
-- Проверяем Бит №2 заявки/сделки (маска 2^2 = 4, то есть 0x4)
-- На Мосбирже: flags & 0x4 ~= 0 означает "Сделка на ПРОДАЖУ"
local is_sell = (flags & 0x4) ~= 0
if is_sell then
   -- Блок выполнится строго если бит присутствует (результат операции равен 4)
end

Вариант 2. Проверка через встроенную функцию bit.test в старых скриптах. Если используете функцию bit.test, она сама под капотом делает сравнение и возвращает чистый булев тип (true или false). Здесь оператор ~= 0 не нужен:
-- В функцию передается не маска, а чистый НОМЕР БИТА (начиная с 0)
local is_sell = bit.test(flags, 2) -- Возвращает true или false
if is_sell then
   -- Код безопасен, так как is_sell — это честный boolean
end
поясню почему в луа все значения true кроме nil,  
Это связано с тем что все данные в луа содержат в неявном виде свой тип
Поэтому  если значение типа не равно нулю то это true а если равно нулю то это false  
У nil значение типа равно нулю.
--------------------------------------
Утверждение :
"Появилась возможность использовать родные поразрядные Си-операторы Lua 5.4.1, которые работают на уровне процессора и не тратят время на вызовы функций."   ошибочно.
Так как значения переменных это не значения СИ а структуры, то для применения бинарных операций  вызываются  функции в соответствии с сохраненным типом переменных.
Поэтому бинарные логические и сдвиговые операции на символьном уровне записываются как в СИ но на уровне исполнения это вызов функций.
----------------------------------  
 
Дествительно не подумал и повелся на маркетинговые мифы о "Си-скоростях". Любое значение Lua — это сложная структура TValue, и побитовые операторы в Lua 5.4 действительно не являются прямыми ассемблерными инструкциями ЦП.

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

Вывод Lua = Таблица, Lua ~= Ассемблер.

Несмотря на то, что на уровне исполнения это вызов функций ВМ, оператор & в Lua 5.4.1 работает быстрее, чем вызов старой внешней библиотеки bit.band(flags, 0x4). Следовательно вывод что встроенный оператор & всё же предпочтительнее для Квика сохраняется и это главное!
Страницы: 1
Читают тему
Наверх