Пользователям trans2quik.dll на заметку!

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Динамический импорт транзакций
Страницы: 1
RSS
Пользователям trans2quik.dll на заметку!
 
#1
12.12.2022 23:50:06
В файле trans2quik_api.h

dwTransID объявлен как DWORD  ( TRANS2QUIK_TRANSACTION_REPLY_CALLBACK и  TRANS2QUIK_ORDER_STATUS_CALLBACK)

На самом деле там LONG (положительные значения)

Пишу, так как все-равно исправлять не будут...
 
 
#2
13.12.2022 05:49:10
Внезапно смотрим в системные хедеры:

>> typedef unsigned long DWORD;
 
 
#3
13.12.2022 07:28:20
читаем внимательно документацию:

DWORD

32-разрядное беззнаковое целое число. Этот тип объявлен в Windef.h как показано ниже:

typedef unsigned long DWORD;
и это не long положительного значения, а беззнаковое число.
Беззнаковое от знакового отличается лишь исполнением операций сравнения на больше меньше
а бинарный код у них одинаковый.
----------------------
Учите мат часть.
 
 
#4
13.12.2022 09:15:11
Внезапно....
Внимательно читаем...


Сами внимательно посмотрите на вложенный файл. И немного пошевелим мозгами!
Посылаем DWORD, а возвращается Long (максимально положительная часть)
 
 
#5
13.12.2022 09:19:46
Посылаемый DWORD больше положительной части LONG, trans2quik (без ошибки) сам кастрирует DWORD до максимально положительного LONG!!!
 
 
#6
28.01.2023 08:13:31
Наконец-то добрался чтобы проверить.
1. Мое сообщение #2говорило о том, что DWORD и LONG одно и тоже. Я не внял что сыр-бор изза знаковости.
2. Проверил, да, квик через транс2квик обрезает dwTransID если он больше "максимально положительного LONG".

Но, при этом в документации написано (см. скрин) "Указатель типа Long", т.е. никто не обещаел что с числом будут обращаться как с беззнаковым.
Согласен, что есть расхождение в прототипе, и описании, и наверное это все-таки баг.

Но, признайтесь честно, вы уже подаете 2млрд. транзакций в течении одного торгового дня, и вам не хватает знакового диапазона чтобы покрыть свои нужды?
Или тут принципиальный момент?
 
 
#7
06.02.2023 12:59:29
Цитата
Kalmar написал:
Наконец-то добрался чтобы проверить.
1. Мое сообщение  #2 говорило о том, что DWORD и LONG одно и тоже. Я не внял что сыр-бор изза знаковости.
2. Проверил, да, квик через транс2квик обрезает dwTransID если он больше "максимально положительного LONG".

Но, при этом в документации написано (см. скрин) "Указатель типа Long", т.е. никто не обещаел что с числом будут обращаться как с беззнаковым.
Согласен, что есть расхождение в прототипе, и описании, и наверное это все-таки баг.

Но, признайтесь честно, вы уже подаете 2млрд. транзакций в течении одного торгового дня, и вам не хватает знакового диапазона чтобы покрыть свои нужды?
Или тут принципиальный момент?
Добрый день!
Дело в том, что я Генерирую автоматически dwTransID на основе имен фьючерсов,
В старших байтах DWORD хранится имя фьючерса, а два младших байта 4096 вариантов dwTransID за торговый день.
А в моем приложении работают от 99 до 134 экспертов (роботов), каждый из них использует свой (уникальный) dwTransID.
 
 
#8
06.02.2023 13:03:22
Вот здесь, код (MQL5) как реализован dwTransID

https://www.mql5.com/ru/forum/401229/page4#comment_44579294

 
 
 
#9
06.02.2023 19:21:51
Поразбирался в скрипте. Если я все правильно понимаю, и строки вида "month<<=24;" - это оператор битового сдвига, то имеем такую картину:

номера битов (пример для RTS-3.23), тут должен быть моноширинный шрифт чтобы табличка правильно выглядела.
64------56------48------40------32------24------16------08------00
| "R"   | "T"   | ----- | ----- | month | year  | sov_id| ------

"R", "T" - первые символы слова RTS, а "-----" - это пустые, ничем не заполненные биты.
все верно?

тогда у меня такие вопросы:
1) данная схема подходит, если sizeof(long) == 8, что правильно выглядит в коде mql, но неверно для с++ под win32, тут sizeof(long) == sizeof(DWORD)=4, т.е. старшие 32 бита куда-то теряются или преобразуются(каким образом?) в младшие 32. это как-то учитывается?
2) где в представленной схеме  "а два младших байта 4096 вариантов dwTransID за торговый день"?
это биты с 32 по 48?, их нет в виндовом long-e.
3) чем должны заполняться биты 0-8?
4) в скриншоте выше, на вход подается число 2207346689, это 0x83917001, но 8391 не похожи на месяц/год. видимо примешиваются еще биты.
каким образом?

я затрудняюсь определить язык на первом скрине, но судя по begin-end, это похоже на паскаль.
можно показать больше кода в этом месте?
 
 
#10
07.02.2023 14:09:41
Добрый день!

Фьючерсы имеют имя не боле 6 байт
Вы правильно все поняли. В старших 6 байтах имя символа а младшие байты служат для генерации уникальных ID.
Если имя меньше, н-р RTS, то 4 байт просто не заполняется.
В случае с MQL мне достаточно 1 байта для генерации уникальных ID для каждого советника.
В Квик мне нужно более 256 переборов. При отсылке ордера к существующему ID прибавляется 1, если значение = 4096,
то счетчик "обнуляется".
Я переделал под Квик генерацию ID.
К сожалению, я сейчас не дома и не могу выложить код генерации
 
 
#11
07.02.2023 16:24:59
Вот так, для Квик, генерится Trans ID
function CalcTransID(const Data: string; const idx: integer): Dword;
var
 k, z: integer;
 Value: Dword;
 month, year: string;
begin
 if(idx < 0) then
 begin
   result:= 0;
   exit;
 end;
 k:= Pos('-', Data);
 z:= Pos('.', Data);
 month:= Copy(Data, k + 1, z - k - 1);
 year:= Copy(Data, z + 1, Length(Data) - z);
 if(TryStrToInt(month, k) = true) then
 begin
   Value:= k;
   if(TryStrToInt(year, k) = true) then
   begin
     Value:= Value + k;
     result:= (idx shl 24);
     Result:= Result + Value shl 16;
   end else result:= 0;
 end else result:= 0;
end;
А так берется, при отправке ордера
TTRansID = packed record
   ID: Dword;
   Value: Dword;
 end;

FTransAction: TTRansID;

function TExpert.GetTransID;
begin
 FTransAction.Value:= TransAction.Value + 1;
 if(TransAction.Value >= 65530) then FTransAction.Value:= 0;
 result:= TransAction.ID + TransAction.Value;
end;

Пишу для Квик на Паскале (Delphi XE4)
 
 
#12
09.02.2023 18:00:25
>>Вы правильно все поняли. В старших 6 байтах имя символа
>>а младшие байты служат для генерации уникальных ID.
К сожалению понял я тут далеко не все.
Но тут хочется отметить, что DWORD - это всего 4 байта, а не 8!

Итак, что у нас здесь (опять рассматриваем для RTS-3.23):

function CalcTransID(const Data: string; const idx: integer): Dword;
... //незначащая часть пропущена
k:= Pos('-', Data); // k=3
z:= Pos('.', Data); // z=5
month:= Copy(Data, k + 1, z - k - 1); // month="3"
year:= Copy(Data, z + 1, Length(Data) - z); // year="23"
if(TryStrToInt(month, k) = true) then
begin
  Value:= k; // Value=3
  if(TryStrToInt(year, k) = true) then
  begin
    Value:= Value + k; // Value=3+23=26 (0x1A)
    result:= (idx shl 24); // сдвигаем idx в старший (3й) байт (из 4х),
//таким образом, если у вас idx>127, то старший бит переполняется и получается число больше INT_MAX
//я незнаю как поступает паскаль с лишними битами, полагаю просто теряет.
    Result:= Result + Value shl 16; //добавляем месяц/год - наше 26 (0x1A) в 2й байт.
  end else result:= 0;
end else result:= 0;
end;
И, собственно все. Имя фьючерса здесь никак не учитывается.
А два младших байта (1й и 0й) видимо дают 65535 вариантов TransID-ов.

Это никак не объясняет происхождение числа 0x83917001, из первого поста.
По вышеприведенной логике 0x83 - это номер робота? - это 131, уже переполнение.
Но 2й байт - 0х91 - не похож на месяц/год.
Да и 0х7001 - 28673я транзакция?

Возможно где-то еще что-то примешивается?
 
 
#13
09.02.2023 19:07:08
Хочу поинтересоваться, что дает запись кода фьючерса в id.
если можно, то интересует численная оценка выигрыша относительно целочисленного id.
Номера советников можно написать в старших байтах.
Я так раньше делал.
Типа 32 бита в итоге
1024 советника  и 4194304 (4 миллиона) заявки в день для каждого из них.
------------------------
Чего уж проще.
 
 
#14
09.02.2023 19:09:06
До встраивания VMLUA в  QUIK тоже писал с использованием trans2quik.dll.
 
 
#15
09.02.2023 19:13:40
для справки.
В луа строки хранятся как числа в виде хеш кода.
поэтому нет проблемы в поиске по таблицам
Сравнение выполняется не над строками а над числами.
 
 
#16
10.02.2023 12:35:35
Цитата
nikolz написал:
Хочу поинтересоваться, что дает запись кода фьючерса в id.
если можно, то интересует численная оценка выигрыша относительно целочисленного id.
Номера советников можно написать в старших байтах.
Я так раньше делал.
Типа 32 бита в итоге
1024 советника  и 4194304 (4 миллиона) заявки в день для каждого из них.
------------------------
Чего уж проще.
Дело в том, чтоMDI приложении работают одновременно от 97- до 134 роботов.
Ордера я отсылаю асинхронно.
При генерации dwTransID каждым из роботов, неизбежно дублирование ID,
поэтому нужно делать уникальные ID
 
 
#17
10.02.2023 12:51:51
Цитата
Kalmar написал:
end;
И, собственно все. Имя фьючерса здесь никак не учитывается.
А два младших байта (1й и 0й) видимо дают 65535 вариантов TransID-ов.

Это никак не объясняет происхождение числа 0x83917001, из первого поста.
По вышеприведенной логике 0x83 - это номер робота? - это 131, уже переполнение.
Но 2й байт - 0х91 - не похож на месяц/год.
Да и 0х7001 - 28673я транзакция?

Возможно где-то еще что-то примешивается?
Дело в то том, что я много пишу на MQL, там wdTransID - это Magic, объявленный как ULong
Вот я, по привычке, для Квик использовал ULong, посылая Ulong я получал кастрированный Long/
Потом, переписал под DWORD
 
 
#18
10.02.2023 17:04:19
Цитата
Михаил Филимонов написал:
1024 советника  и 4194304 (4 миллиона) заявки в день для каждого из них.

Дело в том, чтоMDI приложении работают одновременно от 97- до 134 роботов.
Мне тоже кажется, что можно 9 бит использовать под идентификатор советника - 512 значений более чем достаточно.
Оставшиеся 22 можно использовать под TransID.
Знаковый (старший) бит не трогаем, чтобы не было переполнения.
И никаких проблем.

Цитата
Михаил Филимонов написал:
Потом, переписал под DWORD
Т.е. сейчас никакой проблемы нет?
 
 
#19
10.02.2023 19:18:40
Цитата
Kalmar написал:
Цитата
Михаил Филимонов написал:
1024 советника  и 4194304 (4 миллиона) заявки в день для каждого из них.

Дело в том, чтоMDI приложении работают одновременно от 97- до 134 роботов.
Мне тоже кажется, что можно 9 бит использовать под идентификатор советника - 512 значений более чем достаточно.
Оставшиеся 22 можно использовать под TransID.
Знаковый (старший) бит не трогаем, чтобы не было переполнения.
И никаких проблем.

Цитата
Михаил Филимонов написал:
Потом, переписал под DWORD
Т.е. сейчас никакой проблемы нет?
Да, все работает нормально
 
 
#20
10.02.2023 21:10:50
Цитата
Михаил Филимонов написал:
Цитата
nikolz написал:
Хочу поинтересоваться, что дает запись кода фьючерса в id.
если можно, то интересует численная оценка выигрыша относительно целочисленного id.
Номера советников можно написать в старших байтах.
Я так раньше делал.
Типа 32 бита в итоге
1024 советника  и 4194304 (4 миллиона) заявки в день для каждого из них.
------------------------
Чего уж проще.
Дело в том, чтоMDI приложении работают одновременно от 97- до 134 роботов.
Ордера я отсылаю асинхронно.
При генерации dwTransID каждым из роботов, неизбежно дублирование ID,
поэтому нужно делать уникальные ID
А если вместо фьючерсов будут акции или опционы - тогда кирдык Вашей схеме?
----------------------
Я делал все гораздо проще  номер робота в старшие  10 бит  (1024 робота одновременно )и вся проблема решена
и не имеет значение чем торгуем  
 
 
Страницы: 1
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2025,
ARQA Technologies
Наверх