Andrey Perchits (Все сообщения пользователя)

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1
Не снимаются заявки в секции FORTS
 
Я видел эту ссылку, но мне не нужно снимать все заявки, мне нужно снять именно конкретную заявку и ловить по ней события. И благодаря помощи участников форума проблему мне удалось решить.
QuantPro Platform https://quantpro.ru
Не снимаются заявки в секции FORTS
 
Знаете, а Вы, скорее всего, правы. Я делаю преобразование с помощью lua_tonumber, а оказывается, что начиная с версии 5.3 lua_Integer - это 64-битный целый тип и можно использовать lua_tointeger. Большое спасибо за помощь, коллективный разум - это сила )
QuantPro Platform https://quantpro.ru
Не снимаются заявки в секции FORTS
 
У меня C++, преобразование идет напрямую из Lua Number в uint64_t, а потом уже пишется в лог. По всей видимости, дело действительно в ошибках преобразования из double в uint64_t, судя по https://www.lua.org/pil/2.3.html
Если это так, то возникает резонный вопрос к разработчикам - собираются ли они это исправлять и когда. Учитывая, что Lua не имеет целочисленных типов, а биржа транслирует значения за пределами значений double, тут видится два варианта: или разбивать число на две части и передавать в двух полях, или сделать просто строковое поле.
QuantPro Platform https://quantpro.ru
Не снимаются заявки в секции FORTS
 
Цитата
paluke написал:
Проверил у себя. На quik 10.1 order_num в OnTransReply имеет тип integer, и номер там без искажений, совпадает с тем что в result_msg.
Автор, а брокер у вас какой?  
БКС. Проверял на разных версиях, везде одно и то же.
QuantPro Platform https://quantpro.ru
Не снимаются заявки в секции FORTS
 
Цитата
nikolz написал:
ваш пример не корректный
в нем есть неявный формат печати. Вы уверены что он 64 битный?
Если вопрос ко мне, то да, все значения 64-битные. К тому же, если бы имел место некорректный формат печати, то он был бы некорректен во всех случаях. Но это, как Вы можете видеть, не так.
QuantPro Platform https://quantpro.ru
Не снимаются заявки в секции FORTS
 
Вадим Никитин,

Спасибо, но это не тот случай. Попытки отправить по нескольку раз не увенчиваются успехом. А вот при подстановке значения из result_msg заявки прекрасно снимаются, собственно, что и следовало ожидать, так как они всегда совпадают со сначением из таблицы заявок. Пока мне пришлось закостылить регулярку и вытаскивать этот номер из result_msg, но согласитесь, что этот способ так себе решение. Все же хотелось услышать мнение кого-нибудь из разработчиков по данному вопросу.
QuantPro Platform https://quantpro.ru
Не снимаются заявки в секции FORTS
 
Цитата
nikolz написал:
В OnTransReply может и не быть order_num, так как это ответ сервера брокера на обработку транзакции.
Первый раз этот ответ приходит раньше, чем ответ с сервера биржи.

Действительно, Ваш ответ можно было бы принять, но есть нюанс. В поле  result_msg номер заявки присутствует, и он всегда верный. Так что проблема явно на стороне квика, уж не знаю там, сервера или клиента. В моем первом сообщении Вы можете увидеть оба случая, когда номера совпадают и когда нет.
QuantPro Platform https://quantpro.ru
Не снимаются заявки в секции FORTS
 
В колбеке OnOrder тот же самый order_num, что и в OnTransReply, поэтому его для снятия заявки использовать не получится. А вот брать из таблицы действительно можно, только выглядит это очень уж коряво. И вопрос остается: почему в OnTransReply order_num не совпадает с тем, который в таблице заявок. И еще более удивительно, что иногда они все-таки совпадают.
А вот для фондовой секции они совпадают всегда и я спокойно могу использовать order_num из данных, приходящих в OnTransReply.
QuantPro Platform https://quantpro.ru
Не снимаются заявки в секции FORTS
 
Добрый день.

Обнаружил странное поведение при выставлении заявок на FORTS. Поле order_num, приходящее в колбеке OnTransReply, часто не совпадает со значением в таблице заявок квика, из-за этого не удается программно снять заявку. Тем не менее, бывают редкие случаи, когда эти значения совпадают, и тогда заявки снимаются.
При этом обнаружил, что в поле result_msg номер заявки всегда верный. Вот реальные примеры совпадающих номеров и несовпадающих:
Код
trans_id: 10000001,
order_num: 1951785056590629888,
status: 3,
result_msg: Заявка 1951785056590629888 успешно зарегист,
class_code: SPBFUT,
sec_code: SiM3
Код
trans_id: 10000003,
order_num: 1951785056590630912,
status: 3,
result_msg: Заявка 1951785056590630794 успешно зарегист,
class_code: SPBFUT,
sec_code: SiM3

Подскажите, пожалуйста, в чем может быть проблема и как можно достоверно получить правильный номер заявки?
QuantPro Platform https://quantpro.ru
Ошибка получения параметра "order_num" поля таблицы "orders" через lua_CApi.
 
Цитата
Suntor написал:
Цитата
SG   написал:
У вас переполнение типа int. Номера заявок и сделок - это 64-битные целые числа.
SG прав...

ошибка в строчке:
Код
  int N  =  lua_tonumber(L,  -  1 );  
добавлю только, что судя по определению:
Код
  typedef double lua_Number;
lua_Number lua_tonumber (lua_State  * L, int index);
  
произошло преобразование значения типа double превышающего максимально возможное значение типа int, в результате чего было получено значение INT_MIN из <climits> (limits.h)
Код
   # define INT_MIN     ( -  2147483647   -   1 ) / *  minimum (signed) int value  * /  
Тем не менее, должен заметить, что проблема до конца не решается. Судя по официальной информации, диапазон поддерживаемых целых чисел ограничен 100 000 000 000 000.  https://www.lua.org/pil/2.3.html
QuantPro Platform https://quantpro.ru
Исключение при вызове функции getSecurityInfo()
 
Забыл упомянуть, что исключение возникает при вызове lua_next().
QuantPro Platform https://quantpro.ru
Исключение при вызове функции getSecurityInfo()
 
Добрый день.

К сожалению, не нашел, где у вас баг-трекер, поэтому пишу сюда.

Я разрабатываю коннектор для алгоритмической торговли через интерфейс C++ - Lua. В lua скрипте только лишь загружается библиотека, весь остальной функционал реализован на C++.
Выяснилось, что в момент вызова функции getSecurityInfo() в случае, если у терминала нет информации по запрашиваемой бумаге, он возвращает данные по бумаге, по которой у него был в последный раз удачный вызов. Если же до этого не было вызовов данной функции, терминал прекращает работу скрипта с сообщении о необработанном исключении. Могу предположить, что в этот момент в самом терминале происходит чтение неинициализированной памяти или нечто в этом роде.

Пример кода:

Код
boost::shared_ptr<Security>
initFirstLegalSecurity(std::string const& class_code, std::string const& sec_code)
{
  boost::shared_ptr<Security> result;

  lua_getglobal(lua_state_, "getSecurityInfo");
  lua_pushstring(lua_state_, class_code.c_str());
  lua_pushstring(lua_state_, sec_code.c_str());

  int result = lua_pcall(lua_state_, 2, 1, 0);
  if(result == 0)
  {
    result = boost::shared_ptr<Security>(new Security(class_code, sec_code));
    int item_idx = lua_gettop(lua_state_);
    lua_pushnil(lua_state_);
    while(lua_next(lua_state_, item_idx) != 0)
    {
      std::string key = lua_tostring(lua_state_, -2);
      if(key == "scale")
        security->setScale(lua_tonumber(lua_state_, -1));
      else if(key == "lot_size")
        security->setLotSize(lua_tonumber(lua_state_, -1));
      else if(key == "min_price_step")
        security->setMinPriceStep(lua_tonumber(lua_state_, -1));
      lua_pop(lua_state_, 1);
    }
  }
  lua_pop(lua_state_, 1);
  return result;
} 

С уважением,
Андрей.
QuantPro Platform https://quantpro.ru
Страницы: 1
Наверх