TGB, Ну, в таком случае "длинный цикл" имеет смысл разве что для написания дурацких тестов, потому как обычный здравый смысл запрещает пользователю написать "содержательный фрагмент кода без использования C-функций и исполняющийся достаточно долго". Самый длинный цикл в моём скрипте - по тикерам, за которыми он следит, т.е. обычно несколько сотен. И только один раз он составил 20000 или чуть больше - это когда я хотел посмотреть на бумаги Финама. Но даже тогда всё работало и ничего не отвисало. Так что у меня даже фантазии не хватает, кому и зачем может понадобиться такой "длинный цикл". Разве что nikolz для написания подобных текстов.
Пользователь
Сообщений: Регистрация: 25.09.2020
16.06.2022 17:31:20
Вчера и сегодня поймал редко встречающуюся ошибку в прерывании OnTrade. Не только редкую, но и давно компенсированную "заочно" кодом моего скрипта. Ошибка такая: в данных от прерывания приходит нулевое значение trans_id. Поскольку прерывания приходят пачками, а ошибка редкая, то одно из них скорее всего будет обработано, второе отловлено как дубль и проигнорировано, а это интерпретировано как "сделка по левой заявке" (у меня такие сделки тоже игнорируются). Но, господа, это же МОЯ айдишка, это НА МЕНЯ возлагается обеспечение её уникальности, так какие могут быть нули? Откуда им взяться? И это на 146% ошибка именно ПО Квика - ни брокеру, ни бирже до моей айдишки нет никакого дела. Непорядок...
Пользователь
Сообщений: Регистрация: 12.05.2020
16.06.2022 17:44:33
Цитата
TGB написал: 4. В файле lvm.с после строки: StkId ra; /* instruction's A register */ добавить: int const Период_переключения_State = 1000; if (++L->Счетчик_для_переключения_State > Период_переключения_State) { L->Счетчик_для_переключения_State = 0; // ! Имитация вызова "пустой" C-функции -- ProtectNT((lua_unlock(L), lua_lock(L))); }
Строка: ProtectNT((lua_unlock(L), lua_lock(L))); ошибочна (выяснилось при длительном, недельном тестировании) и ее следует заменить на строку: savestate(L, ci), lua_unlock(L), lua_lock(L), updatetrap(ci);
Пользователь
Сообщений: Регистрация: 25.09.2020
29.06.2022 22:19:22
Вдогонку к предыдущему моему сообщению . Ситуация оказалась куда более неприятной, чем я предполагал.
Вот полный код моего обработчика:
Код
function OnTrade(n)
local i;
i=a[0][7][0]+1; -- новый размер стека сделок из прерывания
a[0][7][0]=i; -- записываем изменение
a[0][7][i]={}; -- заводим новый элемент стека
a[0][7][i][0]=n.trans_id; -- ID транзакции
a[0][7][i][1]=n.order_num; -- ID заявки
a[0][7][i][2]=n.trade_num; -- ID сделки
a[0][7][i][3]=n.sec_code; -- ID тикера
a[0][7][i][4]="B"; -- по умолчанию это покупка
if bit.band(n.flags,4)~=0 then a[0][7][i][4]="S";end;
a[0][7][i][5]=n.qty; -- объём сделки в лотах
a[0][7][i][6]=n.price; -- цена сделки
end;
Некоторые пояснения: a[0][7] - стек прерываний. В нулевом элементе хранится размер стека, остальные представляют собой структуры из 7 элементов (каких именно - видно по коду). Стек сделан для того, чтобы не сидеть долго в обработчике и минимизировать риски столкновения прерываний. Поэтому обработчик только забирает оттуда данные, а разбирается с ними "в спокойной обстановке" уже обработчик по таймеру. В большинстве случаев всё работает нормально, но "в меньшинстве", как я уже говорил, вместо ID транзакции прилетает 0. Это было не страшно, поскольку прерывания на одно событие приходят целой пачкой и потому вероятность, что если не все три, то хотя бы одно из них содержит правильные данные, довольно высока. Но сделки у меня продолжали пропадать. Я вывел в отладочную печать все до единого поля элемента стека. Оказалось всё ещё круче: не только айдишка, но и все остальные поля бывают в нуле. Вот фрагменты сегодняшнего лога:
Код
10:04:09 Не нашли - левая сделка по IRAO 0=0 1=0 2=0 4=0 5=0 6=0
10:18:31 Не нашли - левая сделка по RASP 0=0 1=0 2=0 4=0 5=0 6=0
11:40:44 Не нашли - левая сделка по AFKS 0=0 1=0 2=0 4=0 5=0 6=0
Все эти сделки были корректно обработаны, поскольку следом приходили "нормальные" прерывания. А вот картина маслом в тех случаях, когда сделки терялись (тоже из сегодняшнего лога):
Код
10:05:19 Не нашли - левая сделка по MAGN 0=41335830 1=41335830 2=41335830 4=41335830 5=41335830 6=41335830
10:05:19 Не нашли - левая сделка по MAGN 0=41335830 1=41335830 2=41335830 4=41335830 5=41335830 6=41335830
10:05:19 Не нашли - левая сделка по MAGN 0=41335830 1=41335830 2=41335830 4=41335830 5=41335830 6=41335830
10:14:39 Не нашли - левая сделка по VTBR 0=41335877 1=41335877 2=41335877 4=41335877 5=41335877 6=41335877
10:14:39 Не нашли - левая сделка по VTBR 0=41335877 1=41335877 2=41335877 4=41335877 5=41335877 6=41335877
10:14:39 Не нашли - левая сделка по VTBR 0=41335877 1=41335877 2=41335877 4=41335877 5=41335877 6=41335877
11:21:11 Не нашли - левая сделка по ISKJ 0=41336338 1=41336338 2=41336338 4=41336338 5=41336338 6=41336338
11:21:11 Не нашли - левая сделка по ISKJ 0=41336338 1=41336338 2=41336338 4=41336338 5=41336338 6=41336338
11:21:11 Не нашли - левая сделка по ISKJ 0=41336338 1=41336338 2=41336338 4=41336338 5=41336338 6=41336338
11:40:17 Не нашли - левая сделка по CHMF 0=41336414 1=41336414 2=41336414 4=41336414 5=41336414 6=41336414
11:40:17 Не нашли - левая сделка по CHMF 0=41336414 1=41336414 2=41336414 4=41336414 5=41336414 6=41336414
11:40:17 Не нашли - левая сделка по CHMF 0=41336414 1=41336414 2=41336414 4=41336414 5=41336414 6=41336414
11:41:13 Не нашли - левая сделка по BANE 0=41336439 1=41336439 2=41336439 4=41336439 5=41336439 6=41336439
11:41:13 Не нашли - левая сделка по BANE 0=41336439 1=41336439 2=41336439 4=41336439 5=41336439 6=41336439
11:41:13 Не нашли - левая сделка по BANE 0=41336439 1=41336439 2=41336439 4=41336439 5=41336439 6=41336439
Теперь, как видим, там уже не нули, но все поля похожи как однояйцевые близнецы. А знаете, что это за цифири? Это всё те же ID транзакций, только правильные - это я их формировал. Повторяю: это фрагмент лога один неполный день торгов! Не кажется ли вам, что ошибок, мягко говоря, до хрена? И у меня снова фантазии не хватает, как можно написать софт, который способен вытворять ТАКОЕ. И что прикажете делать? Тем более, что функция сверки портфелей тоже глючит.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
30.06.2022 00:13:39
Цитата
Владимир написал: не только айдишка, но и все остальные поля бывают в нуле.
Исходя из представленного кода, в 4-м параметре не может быть нуля от слова совсем. Там должно быть либо "B" либо "S". Значит нули забиваются где-то в другом месте скрипта.
Искать ошибки в своём скрипте, а не скулить на весь форум.
Надо делать так, как надо. А как не надо - делать не надо.
Пользователь
Сообщений: Регистрация: 25.09.2020
30.06.2022 07:28:17
Старатель, Исходя из представленного кода, НЕ ТОЛЬКО "в 4-м параметре не может быть нуля от слова совсем". Его точно так же не может быть от того же самого слова и в других полях тоже: в 0-м должно сидеть trans_id, в 1-м - order_num, во 2-м - trade_num, в 3-м - sec_code, в 5-м - qty, в 6-м - price. И в 99 случаях из 100 они именно там и сидят. И это ЕДИНСТВЕННОЕ место в скрипте, когда в стек что-то ПИШЕТСЯ. Читается - да, в другом месте, в обработчике по таймеру, но, во-первых, там ЧИТАЕТСЯ, а во-вторых, даже если там и были нули, в следующем прерывании, как правило, сидят уже корректные данные, и данные эти готовлю НЕ Я - ни в случае ошибок, ни в каком-либо другом случае. Кстати, когда я впервые обнаружил этот 0 вместо ID транзакции, в остальных полях сидели ПРАВИЛЬНЫЕ значения. Более того: если ХОТЬ В ОДНОМ из трёх прерываний приходят верные данные, сделка корректно обрабатывается. В-третьих, к элементам стека сделок я не прикасаюсь ВААПЩЕ - я даже не уничтожаю этот элемент стека после обработки - должен же и сборщик мусора чем-то заниматься. Наконец, я уже не раз писал, что четверть, если не треть моего кода написана исключительно с целью компенсации глюков системного софта Квика, коих тут просто НЕМЕРЯЯНО, и от версии к версии положение всё ухудшается. В данном случае сделки ТЕРЯЮТСЯ, а теряться они НЕ ДОЛЖНЫ. Я не бог, я могу и ошибаться, но "рукожопость" здесь, как минимум, НЕ ТОЛЬКО у меня.
Пользователь
Сообщений: Регистрация: 25.09.2020
30.06.2022 07:44:09
Старатель, Кстати, да - ошибка моя (по поводу одинаковых значений всех полей) - вот код F:write(ST().."Не нашли - левая сделка по "..a[0][7][i][3].." 0="..a[0][7][i][0].." 1="..a[0][7][i][0].." 2="..a[0][7][i][0].." 4="..a[0][7][i][0].." 5="..a[0][7][i][0].." 6="..a[0][7][i][0].."\n"); В заголовках скопированный нолик поправил, а в самих значениях забыл. Но это не отменяет того факта, что сделки ТЕРЯЮТСЯ, несмотря на то, что прерывания по ним ПРИХОДЯТ. И эта ошибка никуда не исчезла - моя оказалась всего лишь в выводе
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
30.06.2022 09:37:32
Цитата
Владимир написал: Но, господа, это же МОЯ айдишка, это НА МЕНЯ возлагается обеспечение её уникальности, так какие могут быть нули? Откуда им взяться? И это на 146% ошибка именно ПО Квика - ни брокеру, ни бирже до моей айдишки нет никакого дела. Непорядок...
Нет, это ошибка скриптописателя, который не понимает. "прерывания", как вы их называете, приходят в любом порядке. Но это не болажь квика, а особенность работы биржевых API В том случае, если сервер квика получает об биржи информацию о сделке раньше чем информацию о зарегистрированный заявке, он сообщает вам о сделке вызовом ontrade, но про заявку он ещё не знает, биржа это ещё не сообщила. Соответственно и информацию поставленную вами на заявке он сообщить не может, у него сервера квик в этот момент ещё нет такой заявки, он про неё не знает Потом, когда с биржи приходит информация про зарегмюистрированную заявку, в скрипте вызывается снова ontrade, но уже с поставленной информацией о заявке,т.к.теперь появилась возможность все это связать, теперь сервар знает про заявку и сделку. Ещё в этот момент будет вызван onorder, конечно.
А то что вы отправляете - это транзакция а не заявка.
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
30.06.2022 09:53:06
Но вообще конечно смешно читать про такие наивные "открытия" пальцегнутого балбеса. Это сразу с головой выдаёт его реальный уровень.
Пользователь
Сообщений: Регистрация: 25.09.2020
30.06.2022 10:17:31
swerg, Лапуль, Вы где-нибудь у меня видели хоть полсловечка на тему, что "прерывания, как я их называю" (а OnTrade - это именно прерывание) приходят НЕ в любом порядке? А хоть полсловечка на тему, что я отправляю не транзакцию, а заявку? Там открытым текстом для особо одарённых указано, что это именно транзакция, нулевое поле элемента стека прерываний. И при чём тут "сервер квика"? ТЕРМИНАЛ Квике получает информацию ОТ МОЕГО СКРИПТА информацию о заявке! А уж зарегистрирована она или нет - это ЕГО проблемы, а не мои. Я ВААПЩЕ НЕ ПОЛЬЗУЮСЬ OnOrder.
Да, согласен: "смешно читать про такие наивные "открытия" пальцегнутого балбеса. Это сразу с головой выдаёт его реальный уровень". С зеркалом разговорились, лапуль?
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
30.06.2022 11:06:01
Я тебе рассказываю как оно на самом деле. Причём инфу эту ты не найдёшь нигде, она из очень глубокого многолетнего изучения. А ты вместо спасибо продолжаешь выпендриваться по-идиотски. Дурак и напыщеный идиот.
А сервер при том, что терминал лишь передаёт инфу на сервер и получает её с сервера. Терминал вообще не производит содержательного работы со сделкам и заявками. Впрочем, сервер 4вика тоже. Все биржа. И это абсолютно правильно, иначе барак полный выйдет.
Пользователь
Сообщений: Регистрация: 25.09.2020
30.06.2022 12:00:15
swerg, Лапуль, да я в тыщу раз лучше тебя знаю, "как оно на самом деле". Азбучные истины, подаваемые за плод "очень глубокого многолетнего изучения". А ты вместо того, чтобы что-то ПО ДЕЛУ сказать, продолжаешь выпендриваться по-идиотски. Дурак и напыщеный идиот.
Лапуль, я же русским языком сказал, что мне НАСРАТЬ на инфу с сервера - мне нужна правильная информация по МОИМ заявкам, и если эта придурь вместо МОЕЙ ID транзакции подсовывает 0, то это глюк ТЕРМИНАЛА! От него и не требуется "производить содержательной работы со сделкам и заявками" - мой скрипт прекрасно с этим справляется. Сейчас вот вообще всё обложил отладочной печатью, а эта сволочь перестала ошибки давать - ошибка нестабильная. Да ещё и на бирже паника - Газпром грёбнулся почти на 30%. Вроде как золотое время, чтобы всласть порезвиться скрипту, но я лучше подожду - и так количество сделок за полтыщи перевалило - никогда такого не было, а у меня непонятный глюк висит.
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
30.06.2022 12:08:22
От же тупень.... "ошибка нестабильная"
Пользователь
Сообщений: Регистрация: 25.09.2020
30.06.2022 12:43:44
swerg, Лапуль, именно нестабильно проявляющиеся ошибки и есть самые сложные для обнаружения - это тоже азбучная истина.
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
30.06.2022 13:01:28
Это не ошибка. Это результат произвольно го порядка поступления информации с биржи. И, соответственно, произвольного порядка наполнения данных в колбеках скрипта. Если от биржи информация о зарегистрированной заявке пришла раньше информации о случившемся сделке, что происходит в большинстве случаев, то в ontrade приходит сразу полная информация, включая указанный пользователем ID транзакции. Если информация о сделке пришла раньше информации и породившей её заявке, то стачала будет ontrade, в котором часть полей, данные в которые попадают с заявки, будут не заполнены. А после того как с биржи придёт информация о заявке, сервер квика сможет опознать заявку для уже известной ему сделки и вызовет ontrade уже с заполненной информацией в полях про заявку
Пользователь
Сообщений: Регистрация: 25.09.2020
30.06.2022 13:43:37
swerg, Лапуль, ну не надо пороть ахинею с умным видом. Ежу понятно, что информация от биржи поступает в произвольные моменты времени. И я уже давал пару раз предложение, чтобы они сначала накопили все необходимые данные, а уж потом вызывали коллбеки скрипта, ибо несколько прерываний на одно событие есть маразм. И мне совершенно по барабану, что там куда и откуда приходит - я передавал заявку в терминал, и единственное, что знаю я и что обязан знать он - это идентификатор моей транзакции. И я здесь уже писал, что в большинстве случаев, то в ontrade приходит сразу полная информация, включая указанный пользователем ID транзакции и спрашивал, что делать В МЕНЬШИНСТВЕ. И при чём тут сервер Квика? Прерывание вызывает терминал, которому прекрасно известен ID транзакции. За каким хером пользователю нужен этот коллбек, если он в принципе не может определить, по какой именно заявке скрипта он пришёл? И ещё писал, что практически всегда приходят ТРИ прерывания на одно событие и что изредка бывает так, что НИ ОДНО из них не содержит правильных данных. И это есть именно ОШИБКА.
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
30.06.2022 14:18:49
Уточни, в чем ахинея? Я написал как оно устроено. Ты несёшь поток хотелок. Так в чем ахинея, придурок?
Пользователь
Сообщений: Регистрация: 12.05.2020
30.06.2022 15:40:53
1.
Цитата
Владимир написал: Вот полный код моего обработчика:Код function OnTrade(n) local i; i=a[0][7][0]+1; -- новый размер стека сделок из прерывания a[0][7][0]=i; -- записываем изменение a[0][7][i]={}; -- заводим новый элемент стека a[0][7][i][0]=n.trans_id; -- ID транзакции a[0][7][i][1]=n.order_num; -- ID заявки a[0][7][i][2]=n.trade_num; -- ID сделки a[0][7][i][3]=n.sec_code; -- ID тикера a[0][7][i][4]="B"; -- по умолчанию это покупка if bit.band(n.flags,4)~=0 then a[0][7][i][4]="S";end; a[0][7][i][5]=n.qty; -- объём сделки в лотах a[0][7][i][6]=n.price; -- цена сделки end;
Зачем вы заводите новый элемент стека, когда можно было сделать так:
Код
function OnTrade(n)
local i;
i=a[0][7][0]+1; -- новый размер стека сделок из прерывания
a[0][7][0]= i; -- записываем изменение
a[0][7][i]= n; -- записываем таблицу из OnTrade
end;
Вы любите писать длинные и неэффективные программы ? ----- Вместо непонятных числовых индексов можно бы было использовать более содержательные текстовые ключи, например: «Тикер», «История сделок» и т.д. Читабельность вашей программы улучшилась бы, а ее эффективность практически не изменилась. Если насчет эффективности у вас есть сомнения, то проведите эксперименты. ---- Зачем вы вообще «обрабатываете» OnTrade, когда можно бы было периодически (по таймеру) просматривать таблицы orders (Заявки) и trades (Сделки), в которых отображается готовые состояния по выполнению ващих транзакций ? -------------------------------------- 2. Зачем вы наезжаете на swerg? Он действительно сообщил существенную информацию (мне, например, она была неизвестна) и за это ему спасибо.
Пользователь
Сообщений: Регистрация: 25.09.2020
30.06.2022 16:49:48
swerg, Лапуль, я же подробнейшим образом описал, в чём ахинея. Только вот информация полностью определяется приёмником. Распальцованные откровения, что информация от биржи поступает в произвольные моменты времени наверняка известны в любой младшей ясельной группе. Ладно, ещё разок: ахинея, лапуль, в том, что информация приходит с биржи. Это САМ СКРИПТ формирует айдишки заявок! И терминал Квика узнаёт о них раньше всех (если предположить, что брокер или биржа вообще их знают, ибо им-то они уж точно нафиг не нужны. Терминал также прекрасно знает, от кого пришла заявка - он же передаёт управление в коллбек! Так айдишку-то отдай, зараза! Ты же её лучше любой биржи должен знать! А если не знаешь, какого хера коллбек вызываешь?
TGB, Всё наоборот: я люблю писать компактные и эффективные программы. Да, я завожу новый элемент стека и пишу туда то, и только то, что мне требуется записать, а не всю ту хрень, которая пришла в OnTrade. К тому же, имена массивов по многим причинам у меня все числовые. А Ваш пример - это липовая экономия.
Серьёзно? А ну, шайбу! Вот кусочек кода после того, как данные из OnTrade окажутся всё-таки корректными. Не затрахаетесь "место непонятных числовых индексов использовать более содержательные текстовые ключи"?
Код
if a[0][7][i][4]=="B" then if k>0 then
a[n][4][k][l-2]=a[n][4][k][l-2]+a[0][7][i][5];
if a[n][4][k][l-2]==0 then Y(n,k,0,0);
a[n][1][4][k]=0;a[n][1][6][k]=0;
end;else a[n][4][0][l]=a[0][7][i][5];
a[n][4][0][l+1]=a[0][7][i][6];
a[n][1][4][k]=a[n][1][4][k]+2;end;
else a[n][4][k][l-2]=a[n][4][k][l-2]-a[0][7][i][5];
else if a[n][4][0][l-2]==0 then a[n][1][4][k]=a[n][1][4][k]-2;end;
a[n][6]=a[n][6]+l;end;
Или вот кусочек из другого места:
a[n][4][0][a[n][1][4][0]]=a[0][7][i][5];
a[n][4][0][a[n][1][4][0]+1]=a[n][4][k][l-3]-a[n][4][k][l-1]+a[0][7][i][6];
a[n][1][4][0]=a[n][1][4][0]+2;
a[n][4][k][l-2]=a[n][4][k][l-2]+a[0][7][i][5];
a[n][4][k][l-4]=a[n][4][k][l-4]-a[0][7][i][5];
if a[n][4][k][l-2]==0 then
if a[n][4][k][l-4]>0 then Y(n,k,0,0);end;end;
И кто Вам сказал, что читабельность моей программы улучшилась бы? Мы с моим скриптом прекрасно всё читаем. А лучше всего об этом написал 21 год назад один человек (к слову, программист высочайшей квалификации: "Так я же не поленился, скопировал код, и отформатировал его. Клянусь - readability не на грамм не повысилась. Как не понимал ни бельмеса в том, что там творится, так и не понял".
Я несколько раз писал здесь, почему я использую именно OnTrade и крайне редко заглядываю в orders, повторяться лень, так что если интересно, покопайтесь в моих сообщениях. Коротко: я считаю этот вариант самым оптимальным.
Я?! Это он на меня наезжает. Далеко не первый раз, кстати. Камикдзе... Кстати, что за "существенную информацию" он умудрился сообщить? Лично я кроме словесного поноса на грани истерики ничего не заметил.
Пользователь
Сообщений: Регистрация: 12.05.2020
30.06.2022 17:02:12
Цитата
Владимир написал: Коротко: я считаю этот вариант самым оптимальным.
А что же жалуетесь на нестабильность ?
Пользователь
Сообщений: Регистрация: 12.05.2020
30.06.2022 18:04:13
Заинтриговали:
Цитата
Владимир написал: Я несколько раз писал здесь, почему я использую именно OnTrade и крайне редко заглядываю в orders, повторяться лень, так что если интересно, покопайтесь в моих сообщениях.
Из того, что вы писали я это не понял. Поэтому, пожалуйста, объясните, чем вам не подходят данные из таблиц orders (Заявки) и trades (Сделки), если вы будете их проверять с некоторой периодичностью. В этих таблицах хранятся не какие-то «прерывания», а выполненные биржей операции (выставленные заявки и выполненные сделки). Или вам интересно «кувыркаться» с «сырыми» «прерываниями - колбеками», которые то приходят, то не приходят?
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
30.06.2022 18:50:05
Цитата
Владимир написал: Это САМ СКРИПТ формирует айдишки заявок!
Я ж сказал что ты не понимаешь разницу между транзакцией и заявкой. И даже когда я все подробно расписал - ты, дебила кусок, понять прочитанное не сумел.
Ладно, объясняю. Данные из таблицы orders я использую, предпочитая не связываться с глючным софтом Квика - только в случае крайней необходимости. Заявки мне нужны только для того, чтобы их снять как неисполненные (или частично исполненные). Их я и "проверяю с некоторой периодичностью", что бывает довольно редко - примерно 90% моих заявок исполняется. То есть несколько десятков раз в сутки, а то и того меньше. Шастать же по таблице сделок элементарно невыгодно: сделки могут происходить и несколько раз в секунду, и здесь нужно именно прерывание, в котором уже ничего искать не нужно, а только быстренько обработать готовое событие. Скрипту и без того есть чем заняться: он принимает решения о новых сделках, он мониторит рынок, считает и анализирует свечи разных таймфреймов, он рисует всю эту фигню на экране (если не установлен "спящий режим"), а обслуживать сотни или тысячи тикеров не так-то просто. Ему тупо НЕКОГДА ползать ещё и по таблице сделок, в которой непонятно когда и как обновляется информация. Сделка совершена - всё, забыли про неё - она уже обработана! А таблица с течением времени только пухнет, данные там тоже недостоверные, да ещё и всё более затратный поиск. Нафиг нужно такое счастье?
swerg, Меня прям умиляют эти распальцованные неучи. Кто тебе сказал, придурок, что я не понимаю разницу между транзакцией и заявкой? И с какого бодуна ты корчишь из себя учителя? Ах, он "подробно расписал", панимащ! А я тебя об этом спрашивал? Как только увидят знакомое слово, так тут же начинают пытаться изобразить из себя что-то состоятельное. Тьфу на вас!
Пользователь
Сообщений: Регистрация: 12.05.2020
01.07.2022 07:54:32
Цитата
Владимир написал: А таблица с течением времени только пухнет, данные там тоже недостоверные, да ещё и всё более затратный поиск. Нафиг нужно такое счастье?
Ну и пусть таблица пухнет. Вы знаете, что данные в ней более недостоверные, чем колбеки? Откуда все более затратный поиск в ней, если можно обрабатывать только вновь поступившие ее элементы (между циклами ее обработки)? Я не утверждаю, что заявки и сделки надо обрабатывать именно предлагаемым мною способом. Это, всего-навсего, альтернативный и вполне работающий вариант, избавляющий от обработки промежуточных колбеков. В принципе, чем меньше разных колбеков вы используете (при этом решая свои задачи), тем потенциально надежнее ваш скрипт.
Пользователь
Сообщений: Регистрация: 25.09.2020
01.07.2022 08:40:30
TGB, А меня не устраивает, что таблица пухнет. Не устраивает даже поиск по ней, даже по маленькой. Мой скрипт всегда ТОЧНО знает, что ему делать, без всякого поиска. И одно это уже даёт порядок по скорости.
Нет, я не знаю, а только предполагаю, что данные в ней столь же недостоверные, чем в колбеках, если не хуже, ибо системный софт просто УЖАСЕН!
Нет, нельзя "обрабатывать только вновь поступившие её элементы". Во-первых, там данные тоже могут изменяться в случайные моменты времени. Во-вторых, всё равно придётся искать, по какому тикеру эта сделка, по какой заявке, исполнена ли та заявка полностью или частично. В-третьих, я уже сказал, что считаю тот вариант, который использую, самым оптимальным и рассматривать другие просто не хочу.
Я и так использую только ОДИН коллбек, как минимально необходимый. Есть ещё OnStop, но он просто на всякий случай, если случайно кликнуть по кнопке "остановить".
Пользователь
Сообщений: Регистрация: 12.05.2020
01.07.2022 08:49:37
Цитата
Владимир написал: А меня не устраивает, что таблица пухнет.
Хотите вы это или нет таблица все равно пухнет
Пользователь
Сообщений: Регистрация: 12.05.2020
01.07.2022 08:59:42
Цитата
Владимир написал: И одно это уже даёт порядок по скорости.
Интересно где этот порядок по скорости? Сначала, по колбеку вы заносите данные колбека в свой стек, а затем, наверное, по какому-то таймеру обрабатываете свой стек. И где в таком случае порядок по скорости?
Да, стек прерываний у меня обрабатывает четвертьсекундный обработчик - он ничего не ищет, а просто забирает элемент с вершины стека (это тоже довольно редко - обычно стек полностью выбран), а потом ищет его (как раз по ID транзакции) в стеке активных заявок (тот стек тоже редко превышает десяток элементов от всех тикеров, поскольку сделки заявки мои в подавляющем большинстве случаев исполняются немедленно), корректирует данные портфеля и кошелька и, если заявка полностью исполнена, выбрасывает этот элемент уже из второго стека. А 10-секундный пробегается по этому стеку и если время вышло, снимает эту заявку (если она всё ещё активна). Тут как бы пару порядков по скорости не набежало!
Пользователь
Сообщений: Регистрация: 12.05.2020
01.07.2022 09:39:49
Если бы вы это не написали:
Цитата
Владимир написал: Тут как бы пару порядков по скорости не набежало!
то мне комментировать было бы нечего. А так у меня есть предложение как ускорить то, что у вас уже есть. Не надо обрабатывать OnTrade. Четвертьсекундный обработчик - ничего не ищет, а просто забирает только вновь появившиеся заявки из таблицы orders а далее как у вас описано но без обработки вашего стека.
Пользователь
Сообщений: Регистрация: 25.09.2020
01.07.2022 09:48:31
TGB, Да не надо ускорять то, что у меня уже есть! Мой скрипт и сейчас без напряжения обслуживает тысячу тикеров, если не две! А где я теперь столько тикеров наберу? Это на валютных бумагах их много, а здесь их у меня осталось меньше сотни. И на кой мне "просто забирать только вновь появившиеся заявки из таблицы orders", если стек - это таблица Lua, а не таблица QUIK? Прямое обращение к данным, а не через getIten - тут УЖЕ порядок по скорости сидит, не говоря уже про надёжность!
