Владимир (Все сообщения пользователя)

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

Страницы: Пред. 1 ... 8 9 10 11 12 13 14 15 16 17 18 ... 41 След.
Метки в индикаторе, При перезапуске Квика получается наслоение меток
 
Лично я считаю, что необходимо минимизировать ЛЮБЫЕ обращения к системному софту Квика. У меня, слава богу, никогда не было и даже не планировалось никаких меток, никаких графиков, никаких стаканов и, соответственно, никаких проблем, с этим связанных. Какое-то время я надеялся получать от них свечи, но техника их получения настолько ужасна, что давным-давно все свечи считаю сам. Какое-то время я надеялся заставить работать хотя бы утилиту автоматической сверки портфеля с данными брокера, но и это оказалось утопической задачей. Какое-то время я надеялся компенсировать глюки с обнулением ID транзакции, дублируя эту айдишку в поле комментария в наивном предположении, что хотя бы в одном из этой колоды прерываний на одно события хотя бы в одном из этих полей эта айдишка будет прописана правильно, но и это оказалась утопией. А в последние 2-3 дня меня задолбала диагностика "Данный инструмент запрещён для операции шорт". Какой, блин, "данный"? Язык отвалится назвать, какой именно? К тому же, я АБСОЛЮТНО ТОЧНО знаю, что акции эти у меня есть, и столь же точно знаю, что и брокер об этом прекрасно знает. Иногда встречается диагностика "Превышена позиция по деньгам", хотя и я, и скрипт, и брокер прекрасно знаем, что деньги у меня есть. И при этом при всём ещё и новые версии плодятся, как тараканы. Пока вся эта конструкция ещё хоть как-то работает, "но ключевое здесь - пока".
7 часов, кто больше?
 
Павел Bosco, И что? Подтверждаю каждую запятую в своих текстах - в т.ч. двухлетней давности. Что сказать-то хотели? И я никогда НЕ спрашивал, зачем собственно нужен sleep - я спрашивал ЧО ВАЩЕ ЗДЕСЬ ТВАРИЦЦА?!
Кривые шибки в QLua
 
TGB, У меня полностью обратное впечатление: помню свой первый шок, когда я узнал, что ИНТЕРПРЕТИРУЕМЫЙ код способен подвесить Квик. Вылет скрипта (при НОРМАЛЬНОМ системном софте), по моим представлениям, возможен только при ошибках в коде самого скрипта, но здесь... Ещё один шок - несколько прерываний на одно событие, ещё один - убийство целочисленного типа данных, ещё один - динамическая типизация, из-за которой происходит добрая половина обсуждаемых здесь глюков... я давно уже боюсь новых версий, ибо не видел ещё ни одного исправленного глюка - в т.ч. из числа тех, про которые здесь пишут годами, и до сих пор встречаю всё новые и новые, хотя алгоритмически задача простая до неприличия. Эту среду надо не улучшать, а полностью переписывать набело, с нуля.
Кривые шибки в QLua
 
Подсказали бы мне лучше, что такое поле COMMENT при отправке транзакции. Я туда зашарашил дубль её айдишки, надеясь хотя бы по нему идентифицировать сделку, пришедшую по OnTrade, но там я увидел только поле комментария по кличке brokerref, а туда запихивают мой код клиента. А тот комментарий, который я сам давал, где-то из OnTrade вытащить можно?
Кривые шибки в QLua
 
Нафига вам всё это нужно, господа? Я потратил недели две, чтобы вынести всё, что можно, в поток main и уже практически забыл про вылеты скрипта или отвисания Квика. Не говоря уже о том, что я буквально с первого же дня постулировал: никаких библиотек, никаких других языков - скрипт должен работать на любой версии Квика и любой версии языка. И никаких стаканов, никаких свечей, никаких графиков, никаких сокетов. А все вопросы синхронизации/блокировки выполняются самим скриптом, у которого для этого заведены соответствующие стеки и флаги. Ведь наша задача - получить рабочую версию торговой программы, а не вести бесконечную борьбу с глюками всех мастей и размеров.
7 часов, кто больше?
 
О, сколько нам открытий чудных!..

Сегодня попробовал прогнать алгоритм по историческим данным - не работает. С чего бы вдруг? Всегда работал, и вот опять. И изменения в коде были вроде как косметические. Причём внешне делает вид, что работает, но считав первые 70 строк из файла данных, остальные читать не хочет (их там порядка 6 миллионов). Чем занимается - непонятно. Стал разбираться - глаза на лоб: локальная переменная в main портится! Та самая, которая внутри бесконечного цикла крутится. Она у меня изменяется от 1 до 8 и управляет вызовом обработчиков. Для балансировки нагрузки на процессор обработчики вызываются со сдвигом: 4 раза в секунду – обработчик стека прерываний. Каждое нечётное срабатывание (2 раза в секунду) – обработчик стека заявок, каждое второе и шестое – секундный (не пересекаясь с 0.5-секундным), каждое восьмое – 2-секундный (не пересекаясь ни с секундным ни с 0.5-секундным). Всё это тыщу лет как отлажено и всегда работало без нареканий. Отключил все модули - работает. Стал подключать по одному - затыкается. И память вдруг стала жрать со страшной силой, раз в 10 больше, чем обычно. Стал выводить значение счётчика - ОБА-НА!
Код
1213456178121345617812134
RUR: 0.00+50000.00=50000.00/0.00 V=50000.00
USD: 0.00+0.00=0.00/0.00 V=0.00
EUR: 0.00+0.00=0.00/0.00 V=0.00
FUT: 0.00+20000.00=20000.00/0.00 V=20000.00
RES: 0.00+0.00=0.00/0.00 V=0.00
Отрубил всё к чертям собачьим, даже обнуление счётчика, и тут меня ожидал удар ниже пояса:
Код
277995
277996
RUR: 0.00+50000.00=50000.00/0.00 V=50000.00
277997
277998
277999
278000
USD: 0.00+0.00=0.00/0.00 V=0.00
278001
278002
EUR: 0.00+0.00=0.00/0.00 V=0.00
278003
278004
278005
278006
FUT: 0.00+20000.00=20000.00/0.00 V=20000.00
278007
278008
278009
RES: 0.00+0.00=0.00/0.00 V=0.00
278010
278011
Или, если оставить обнуление и только его:
Код
123456781
RUR: 0.00+50000.00=50000.00/0.00 V=50000.00
234
USD: 0.00+0.00=0.00/0.00 V=0.00
5678
EUR: 0.00+0.00=0.00/0.00 V=0.00
12345
FUT: 0.00+20000.00=20000.00/0.00 V=20000.00
6781
RES: 0.00+0.00=0.00/0.00 V=0.00
2
Теперь поясняю, что это значит: по OnStop у меня сбрасывается на диск дамп состояния портфеля и в лог выводится состояние кошелька по каждой валюте - вот это самое, что мы видим. Выводится, повторяю, В КОЛЛБЕКЕ: function OnStop()local i;for i=0,4 do F:write(string.format("%s: %1.2f+%1.2f=... А значение счётчика выводится В МЕЙНЕ! Получается, что OnStop в цикле между своими F:write отдаёт управление в main, а потом каким-то образом снова захватывает его себе или как? У меня просто крыша едет, в голове не укладывается, как вообще может такое происходить.

И тут меня осенило: в боевом режиме в цикле мейна стоит sleep(250), а при работе по историческим данным этой задержки нет (в результате чего двухмесячный тиковый массив пролетает за пару минут). Поставил туда sleep(1) и - О, ЧУДО!
Код
1234567812345
RUR: 0.00+50000.00=50000.00/0.00 V=50000.00
USD: 0.00+0.00=0.00/0.00 V=0.00
EUR: 0.00+0.00=0.00/0.00 V=0.00
FUT: 0.00+20000.00=20000.00/0.00 V=20000.00
RES: 0.00+0.00=0.00/0.00 V=0.00
Версия Квика СТАРАЯ, много раз по историческим данным работала, в Интернет вообще не входил, биржа не работает. Кто-нить может подсказать, ЧО ВАЩЕ ЗДЕСЬ ТВАРИЦЦА?!
Как окрасить отдельные клетки в заданный цвет?, Окрашивание клеток средствами Луа
 
Beginner, А почему все остальное остается серым? Создавали таблицу Вы, значит, и ячейки должны были красить именно Вы. А прописать просто:
SetColor (iTable, iRow, iCol, ClF, ClT,-1,-1);
Как окрасить отдельные клетки в заданный цвет?, Окрашивание клеток средствами Луа
 
Beginner, Индекс ЧЕГО?
Как окрасить отдельные клетки в заданный цвет?, Окрашивание клеток средствами Луа
 
Beginner, Ответы:
0) Нет, и быть не может никакой таблицы, все ряды которой закрашены серым цветом. Её нужно а) создать и б) покрасить все её ячейки в серый цвет
1) Таблица прорисовывается в текстовом режиме, а линии рисуются в графическом, поэтому нарисовать черную горизонтальную линию между 1 и 2 рядом невозможно - можно только эмулировать её отдельной строкой таблицы.
2) Воспользоваться функцией SetColor.
7 часов, кто больше?
 
Nikolay, Я уже писал "зачем так усердно бороться с колбеками" и что не проще и не надежней "самому обрабатывать записи в таблице trades" - ошибки встречаются и там и там. Кстати, последний колбек, который пришёл через 7 часов, был именно "после восстановления соединения с брокером" вместе с несколькими десятками других. Здесь В ПРИНЦИПЕ нет предсказуемого поведения - четверть, если не треть кода моего скрипта посвящена компенсации разных глюков, и это вечный процесс - новые версии Квика штампуются как горячие пирожки. И Вы далеко не всегда сможете "по старинке найти новую запись в таблице". Как правило - да, но и коллбеки, как правило, приходят с верными данными, и работать с ними несравненно удобнее, быстрее и даже надёжнее, чем рыскать по таблицам Квика.
7 часов, кто больше?
 
Фрагмент лога от 28 июля:
Код
10:15:01   Заявка на продажу TID=43851120
10:15:02   Продажа по заявке TID=43851120
10:15:03   Дубль заявки TID=43851120
10:15:03   Дубль заявки TID=43851120
10:15:23   Удаляем паспорт заявки TID=43851120
17:26:02   Не нашли - левая сделка TID=43851120
И это, собственно, ерунда - скрипт информацию о сделке скрипт всё-таки получил, дубли отфильтровал (двумя способами), но портфель и кошелёк изменились так, как надо. А вот потери сделок из-за глюков в данных, получаемых в OnTrade, реально ДОСТАЛИ! Даже специально написанный для компенсации этих глюков нечёткий поиск не всегда помогает! Решил пойти на крайние меры: задублировал ID транзакции ещё и в поле COMMENT, которое рассчитываю получить в коллбеке в поле brokerref. Надеюсь, хоть одно из двух полей хоть в одном из трёх или четырёх прерываниях на одно событие будет всё-таки передано правильно, господа разработчики?
Таблицы в функции
 
Станислав, Убей, не пойму, что Вам нужно. Передавайте хоть таблицу: Algo(S), хоть её поля: Algo(S.Pos, S.MIDDLE_PRICE) - всё должно работать. Лично у меня вообще одна глобальная "супертаблица", и в функции я передаю только имена полей, которые, к тому же, всегда представлены как числовые индексы. Вот, например, есть у меня такая функция Y(i,j,k,l), она переносит k-ю взятку из массива j-го таймфрейма i-го тикера в массив l-го таймфрейма того же тикера. Передаются тупо 4 числа, а сама таблица a не передаётся - она глобальная. А уже внутри функции эти числа интерпретируются как индексы соответствующих полей этой таблицы. В частности, в лог пишется (точнее, писалось, когда я это дело отлаживал):
F:write(ST().."Перенос "..a[i][0][1].." из "..j.." в "..l.." сделки "..k.." лотов "..a[i][4][j][k].." по "..a[i][4][j][k+1].."\n");
И нет проблем! Универсальность выше крыши - переносится любая взятка любого тикера из любого таймфрейма в любой, передача параметров - проще не придумаешь, надёжность тоже вполне приличная, хотя даже здесь эта антиллехтуальная придурь со своей долбаной динамической типизацией умудряется поднасрать, заменяя натуральные числа вещественными, именно в этой функции мне пришлось вставить первой командой: j=tonumber(string.format("%1.0f",j)); о чём я недавно писал. Зачем искать на свою задницу приключений?
Удваиваются заявки. Версия 9.7.1.10., Вопрос разработчикам QUIK
 
nikolz, Как обычно, бред от начала до конца. Не бывает в природе неисполненных транзакций, бывают неисполненные заявки. Само определение транзакции говорит, что она может быть либо исполнена полностью либо не исполнена вообще, никаких промежуточных состояний у неё нет и быть не может - по крайней мере, видимых со стороны.

Какое собачье дело клиента, что там творится на сервере? Нормальные люди заводят стек активных заявок У СЕБЯ В СКРИПТЕ и ждут, когда информация о событиях, происходящих с ними, будет доставлена скрипту, а не лезут своими кривыми ручонками туда, где они только путаются под ногами.

И не надо брехать - в Вашем фрагменте так называемого кода чёрным по белому:
t1.TRANS_ID=tostring(id+1);
То есть айдишка НЕ увеличивается. И это ПЕРВОЕ ЖЕ, что тут написано. И смотреть дальше этот говнокод тупо не возникает ни малейшего желания.
Удваиваются заявки. Версия 9.7.1.10., Вопрос разработчикам QUIK
 
nikolz, Лапуль, Вы можете-хоть 100500 лет разрабатывать свои крутые системы РВ и ИИ - это никак не влияет на тот медицинский факт, что Вы полуграмотный чайник, и в программировании не соображаете от слова совсем - у Вас это написано НА ЛБУ. Код - идиотский, гипотезы - идиотские, подтверждения этому бреду даже в результатах так называемых тестов и близко не просматривается, тон постингов близок к истерике, а это означает, что Вы и сами догадываетесь, что в программировании Вы никто и звать Вас никак.
Удваиваются заявки. Версия 9.7.1.10., Вопрос разработчикам QUIK
 
nikolz, Лапуль, инкрементируйте айдишку КАЖДЫЙ раз. Если верно Ваше бредовое утверждение про близнецов, они ВСЁ РАВНО будут удваиваться в таблице. Квику НАСРАТЬ на эту айдишку, она формируется пользователем. А на Ваш говнокод реально глядеть тошно.
робот в индикаторе
 
nikolz, Всё никак не уймётесь, лапуль? Говно этот Ваш индикатор, ИДЕОЛОГИЧЕСКОЕ говно. И Вы абсолютный чайник, сподобившийся тут ликбезы проводить. Шли бы Вы из программистов, лапуль, куда-нибудь, где Вы ХОТЬ ЧТО-ТО соображаете.
Получить строки таблицы Текущие торги.
 
Алексей, Так добавляйте и удаляйте - в чём проблемы? Что за периодичность? Раз в полгода? :smile:  
Удваиваются заявки. Версия 9.7.1.10., Вопрос разработчикам QUIK
 
nikolz, Хоспидя, через какую жопу можно простейшие действия выполнять... Да в код глядеть тошно, не говоря уже про читать "тщательно разжёванное".
s=sendTransaction(A);
if s~="" then F:write("Result="..s.."\n");end;
Всё остальное на помойку, не читая.
Получить строки таблицы Текущие торги.
 
Алексей, Ах, да -  "Текущие торги #2" и "Текущие торги" это одна и та же таблица
Получить строки таблицы Текущие торги.
 
Алексей, Если Вам нужно это всё именно в Вашем экземпляре таблицы, то Ctrl+E - редактирование таблицы, добавьте туда нужные столбцы, и они в ней появятся. А если нужен программный доступ, то не имеет значения что там находится в таблице и есть ли она вообще.
Помогите разобраться: почему не выставляется заявка на покупку?
 
Аркадий, Вот фрагмент моего кода:
a[i][2][0]=tonumber(getParamEx(a[i][0][0],a[i][0][1],"LAST").param_value);
Тыщу лет работает, как часы. Может, имена переменных как-то конфликтуют с зарезервированными...
Помогите разобраться: почему не выставляется заявка на покупку?
 
Аркадий, Вот уж чего-чего. а Syntax error там точно быть не может.  :smile:  
Помогите разобраться: почему не выставляется заявка на покупку?
 
Аркадий, Скорее всего, дело в этой долбаной динамической типизации. Попробуйте Z=tonumber(getParamEx(....
Позиции на счете появляются уже после снятия заявки, Позиции на счете появляются уже после снятия заявки
 
nikolz, Лапуль, я не только читал, но и много раз писал об этом, начиная с самого первого своего сообщения на этом форуме:


25.09.2020 09:50:33: Я не нашёл тип данных integer ВООБЩЕ! И как же мне работать с битовыми масками? Как на Lua реализуется конструкция вида: if (iData & 0x80) { blah-blah-blah }?

28.09.2020 09:20:15: Нет, похоже, здесь мы друг друга не поняли. Как я могу анализировать указанный бит, если тип данных не integer, а real? Там же, насколько я помню, мантисса с характеристикой, а не двоичное представление числа!

29.09.2020 10:31:16: Убрать тип integer из языка, на мой взгляд, есть самая большая дурость.

29.09.2020 18:25:00: В документации на lua указан только тип number, а он принимает значения с плавающей точкой. Иными словами это тип real (float, double) в других языках программирования, но никак не integer. А что толку мне от флагов терминала? Мне нужен целочисленный тип ДЛЯ СВОИХ данных!

13.03.2021 11:47:57: Преобразование типов (tonumber, tostring) - претензий нет. Но за динамическую типизацию, замену операций булевой алгебры на убожество типа bit.band руки-ноги бы повыдёргивал разработчиком! А уж за убийство типа integer... ТАКОГО маразма я ещё не встречал ни в одном языке - Lua первый!

13.10.2020 18:51:52: В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов!

19.05.2021 16:10:49: Один goto чего стоит! В Си это обычный JMP (в отличие от ассемблера, без возможности межпрограммного перехода), а здесь это кастрированное убожество, нафиг никому не нужное. Про сборщик мусора я ваще молчу. И вершина идиотизма: тип integer вообще уничтожен!

19.06.2021 19:08:23: Я прекрасно понимаю, что абсолютным приоритетом является обеспечение надёжной торговли через терминал QUIK - всё остальное вторично (включая весь Lua с потрохами или наиболее одиозные его моменты вроде динамической типизации или кражи типа integer).

25.03.2021 12:28:31: Язык отвратителен, и только за убийство типа integer и замену его на вонючий "тип number" создателей нельзя подпускать к компу ближе, чем на километр.

03.03.2021 10:13:06: Какие уж тут, к чёрту, "быстродействие и наглядность"? Вместо одной ассемблерной команды - вызов функции, вместо угробленного типа INTEGER и красавцев-операторов типа &, | или >>= убожество с указанием номера бита.

03.03.2021 11:56:56: Да я уже тыщу раз говорил: я НЕ МОГУ записать в переменную значение какого-либо типа - это как уж моча в голову интерпретатору ударит. И это ПЕРВЫЙ попавшийся мне язык за мои 40 лет программирования, в котором уничтожен тип integer! Даже в JS, у которого тоже этот идиотский "тип var") он имеется!

03.03.2021 17:44:47: There are eight basic types in Lua: nil, boolean, number, string, function, userdata, thread, and table. lua_Number. The type of floats in Lua. By default this type is double, but that can be changed to a single float or a long double.

03.03.2021 20:45:39: Повторяю: в языке НЕТ ни типа integer, ни типа float. Если бы они были, не было бы никакой проблемы с 19-значными кодами. И целочисленный тип вовсе не обязательно signed.

04.08.2021 10:49:50: Для меня вот совершенно очевидно, что тип integer обязан быть в языке - это первый язык, который я встретил за долгие годы программирования, в котором его нет!

20.02.2022 15:27:55: И вообще, разделение по потокам - это одна из главных глупостей Lua (после этой долбаной "динамической типизации" и убийства типа integer).

А документацию читайте - на заборе тоже много чего написано. Как раз для Вашего уровня квалификации как программиста.  :wink:  
Позиции на счете появляются уже после снятия заявки, Позиции на счете появляются уже после снятия заявки
 
Glukator, Да, в Вашем случае пользоваться OnTrade почти невозможно - здесь есть ещё один нюанс: после обрыва и восстановления связи прилетает колода старых прерываний, которые уже обработаны. На днях у меня оборвалась связь, скрипт продолжал работать, и после восстановления прилетело штук 50 OnTrade, если не все 100. Благо, у скрипта заведён стек активных заявок, и он всю эту хрень отфильтровал, а если нет, то портфель придётся восстанавливать часа два.

А глюков предостаточно и без проблем со связью. Нули в trans_id прилетают примерно каждую сотую сделку, но чаще всего в одном из трёх (или сколько там - 4?) коллбеков на одно событие хоть в одном из них айдишка нормальная и позволяет провести идентификацию сделки. Но не так уж и редко все прерывания приходят с нулём, и при достаточно большом количестве сделок (как у меня) это начинает раздражать. В общем, написал процедуру нечёткого поиска, которая большинство сделок с "нулями" тоже правильно идентифицирует.

Есть и другие глюки, совершенно уникальные. У меня иногда (очень редко, далеко не каждый день) вылетал скрипт с диагностикой что-то типа "attempt to index a number value". Стал разбираться - оказалось, что когда я вызываю некую функцию с аргументами вроде SomeFunc(1,2) туда приходит "не совсем то": у меня имена полей во всех таблицах целочисленные (типа "индексы") - их я и передаю. Но народные Lua-умельцы тип integer вообще отменили, заменив его на дурацкий тип number (руки бы пообрывал!), а эта антиллехтуальная сволочь со своей долбаной "динамической типизацией" (и ноги тоже!), получив эти аргументы, начинает соображать, что же это такое ей прислали. Нет, в подавляющем большинстве случаев она всё-таки соображает верно, но примерно раз на 10000 вызовов она полагает, что ей прислали не 1, а 1.002345 и пытается по этой белиберде индексироваться. Пришлось вставить на входе самой часто используемой функции j=tonumber(string.format("%1.0f",j)) - пока работает. Но куда дальше занесёт неуемная фантазия разработчиков, просто боюсь себе представить.

nikolz, Лапуль, нормальные люди создают роботов для ГРУППЫ инструментов, и отдают ему на откуп динамическую балансировку портфеля - ему ЛУЧШЕ знать какими конкретно инструментами от будет торговать "в данное время суток".

Что бы Вы понимали в коллбеках, лапуль! Мой робот работает по свечам  на таймах от 10 секунд до 4 часов, и коллбеки ему очень даже нужны при торговле НА ЛЮБОМ таймфрейме. И я уже не раз говорил, что никогда не понимал на кой вообще нужны индикаторы и что слушать "рекомендации" от тех, у кого на лбу выбито крупными буквами "ЧАЙНИК" довольно утомительно.
Позиции на счете появляются уже после снятия заявки, Позиции на счете появляются уже после снятия заявки
 
Glukator, Я тут уже объяснял (кажется, Николаю), почему я использую именно OnTrade и почему это единственный коллбек, который я использую. При этом мне совершенно плевать на все флаги: пришло прерывание - значит сделка совершена. Мне также плевать, отклонена ли она биржей или брокером или просто мою заявку никто не захотел исполнить: сделки не было. Число открытых позиций мой скрипт и так прекрасно знает лучше всякого getFuturesHolding, и потому ему плевать и на него, и на OnTransReply. Цену исполнения заявки можно получить после идентификации заявки, а это гарантируется только через trans_id, вместо которого мне Квик время от времени любезно преподносит 0. И дело не только в том, что "обращения к таблицам QUIK - сравнительно медленные операции", но и в том, что там информация тоже не всегда достоверна.

P.S. Мой робот не выставляет по 10000 заявок в час, но 7200 теоретически может - ограничение стоит не более двух заявок в секунду. :smile:  
Позиции на счете появляются уже после снятия заявки, Позиции на счете появляются уже после снятия заявки
 
Дмитрий, Сделка-то всё равно одна, хоть 100500 раз по ней коллбек вызывать.
Позиции на счете появляются уже после снятия заявки, Позиции на счете появляются уже после снятия заявки
 
Дмитрий, Я когда-то тоже спрашивал "почему OnTrade вызывается по каждой сделке ровно 3 раза, а не один". И даже пару раз регистрировал пожелание, чтобы убрать этот маразм (как и многие другие пользователи в течение многих лет). Теперь, по слухам, она вызывается уже не 3, а 4 раза. На днях тут обсуждалось и высказывалось сожаление, что не 5.
Позиции на счете появляются уже после снятия заявки, Позиции на счете появляются уже после снятия заявки
 
Дмитрий, Не знаю, как прогрессивный люд, а я делаю только так. Только ещё нюанс: функция сверки с портфелем тоже глючит, и в данный момент она у меня отключена.  
Позиции на счете появляются уже после снятия заявки, Позиции на счете появляются уже после снятия заявки
 
Дмитрий, А зачем Вы вообще связываетесь с getFuturesHolding? Вы знаете, что заявка исполнена (или исполнена частично, или не исполнена вообще). Портфель тоже нередко глючит (это если у брокера его смотреть). Так контролируйте всё, что угодно по собственным данным скрипта, ведите портфель сами, периодически сверяясь с брокером.
Пустое значение trans_id в таблице сделок.
 
Старатель, Во-первых, где можно посмотреть на "новые правила"? До знакомства с Квиком я наивно полагал, что на одно событие должно быть только ОДНО прерывание, а все остальные варианты есть маразм. Во-вторых, пусть хоть по 124 колбека на одну сделку присылают - текущая версия скрипта спокойно отфильтрует "лишние" 123. Но эти же падлы ещё и значения полей "варьируют"! В частности, "пустое значение trans_id в таблице сделок" и не только. Что с того, что "в большинстве случаев, все четыре OnTrade абсолютно одинаковые"? С меньшинством что делать прикажете? Я уже собрался отлавливать сделки нечётким поиском, по совпадению или хотя бы правдоподобию хоть части полей.

Nikolay, Да, "формулировка разработчиков была - есть изменения во внутренних полях, недоступных для чтения, все равно получите callback" - в частности, лично мне так отвечали (не помню кто, не помню когда, да уже и не интересно).
Пустое значение trans_id в таблице сделок.
 
Сергей, Мой скрипт не просматривает таблицу сделок, а получает данные по OnTrade, но довольно часто (раза 2-3 на сотню сделок) встречается именно такая ситуация. Сегодня, например, она встретилась уже 4 раза. Значение trans_id формирует сам пользователь (в смысле, скрипт), а потому появление там нулей однозначно глюк Квика: уж кто-кто, а он ОБЯЗАН её знать!
Беспрерывная робота робота, Как сделать так, чтобы робот был постоянно в работе и обрабатывал каждый тик?
 
БорисД,  Нет, недели две я здесь ещё точно пробуду. Кроме того, есть вероятность, что я умотаю в Белоруссию - тоже на неделю-другую. А письма твоего я и не видел. Да, что-то пришло, сейчас посмотрю. Ты мне пришли свой IN/OUT - сам ты в нём вряд ли сумеешь поправить, а последняя версия с ним работать не будет. А там посмотрим, что и как.

Мало ли что релиз обновился. Твоя последняя версия достаточно резко отличалась от предыдущей, хотя и не так сильно как нынешняя. А боевой режим пока лучше и не запускай - слишком много изменений.

 
Отладка QUIK 8.13
 
TGB, Да не надо ускорять то, что у меня уже есть! Мой скрипт и сейчас без напряжения обслуживает тысячу тикеров, если не две! А где я теперь столько тикеров наберу? Это на валютных бумагах их много, а здесь их у меня осталось меньше сотни. И на кой мне "просто забирать только вновь появившиеся заявки из таблицы orders", если стек - это таблица Lua, а не таблица QUIK? Прямое обращение к данным, а не через getIten - тут УЖЕ порядок по скорости сидит, не говоря уже про надёжность!
Отладка QUIK 8.13
 
TGB, Ну и пусть пухнет - я же ею не пользуюсь! :smile:

Да, стек прерываний у меня обрабатывает четвертьсекундный обработчик - он ничего не ищет, а просто забирает элемент с вершины стека (это тоже довольно редко - обычно стек полностью выбран), а потом ищет его (как раз по ID транзакции) в стеке активных заявок (тот стек тоже редко превышает десяток элементов от всех тикеров, поскольку сделки заявки мои в подавляющем большинстве случаев исполняются немедленно), корректирует данные портфеля и кошелька и, если заявка полностью исполнена, выбрасывает этот элемент уже из второго стека. А 10-секундный пробегается по этому стеку и если время вышло, снимает эту заявку (если она всё ещё активна). Тут как бы пару порядков по скорости не набежало!
Отладка QUIK 8.13
 
TGB, А меня не устраивает, что таблица пухнет. Не устраивает даже поиск по ней, даже по маленькой. Мой скрипт всегда ТОЧНО знает, что ему делать, без всякого поиска. И одно это уже даёт порядок по скорости.

Нет, я не знаю, а только предполагаю, что данные в ней столь же недостоверные, чем в колбеках, если не хуже, ибо системный софт просто УЖАСЕН!

Нет, нельзя "обрабатывать только вновь поступившие её элементы". Во-первых, там данные тоже могут изменяться в случайные моменты времени. Во-вторых, всё равно придётся искать, по какому тикеру эта сделка, по какой заявке, исполнена ли та заявка полностью или частично. В-третьих, я уже сказал, что считаю тот вариант, который использую, самым оптимальным и рассматривать другие просто не хочу.

Я и так использую только ОДИН коллбек, как минимально необходимый. Есть ещё OnStop, но он просто на всякий случай, если случайно кликнуть по кнопке "остановить".
Беспрерывная робота робота, Как сделать так, чтобы робот был постоянно в работе и обрабатывал каждый тик?
 
БорисД, Зато Серега уже умеет пользоваться меню по таймфреймам "в корыстных целях", а ты ещё нет. И с новой структурой IN-файла ты пока не справишься, а он уже как-то разбирается. А в алгоритмах, правилах и блокировках для  обхода этих правил даже я не совсем объёмно всё понимаю.

А зачем ты его отключил? Я же тебе говорил: запусти его в тестовом режиме - ты же умеешь! Глядишь, добрая половина вопросов уже бы снялась. А "результаты торговли за месяц" обсуждать практически невозможно: ни ты, ни он в логи почти не смотрите, а основное обсуждение именно там. Вот вчера был интересный день: Газпром объявил, что хрен вам, а не дивиденды, и его акции тут же рухнули на 30%. А за ним и весь остальной рынок резко пошёл на снижение. Только какой-то придурок (то ли Камаз, то ли Иркут) "плыл против течения". Я-то пытался поймать один "мерцающий" глюк (описан в соседней ветке), несколько раз останавливал торги, а у Серёги рекордное количество сделок вообще за всё время! А теперь представь, что делала бы твоя любимая старая версия: сидела бы в своей ярко-красной жопе с парой-тройкой случайных сделок, а то и вовсе без них. И это было бы самой правильной линией поведения при её куцых возможностях. И вообще, приехал бы ты лучше "живьём" на пару деньков на "мозговой штурм": последний бой - он трудный самый. В  т.ч. и для шлифовки алгоритмов под твой любимый срочный рынок (хотя даже там у меня вопросов почти не осталось).
Беспрерывная робота робота, Как сделать так, чтобы робот был постоянно в работе и обрабатывал каждый тик?
 
БорисД, Серега уже всё видел, щупал и нюхал - только ты у нас ещё остался неохваченный. :smile:  
Отладка QUIK 8.13
 
TGB, Я сроду ни на кого и не на что не жалуюсь.

Ладно, объясняю. Данные из таблицы orders я использую, предпочитая не связываться с глючным софтом Квика - только в случае крайней необходимости. Заявки мне нужны только для того, чтобы их снять как неисполненные (или частично исполненные). Их я и "проверяю с некоторой периодичностью", что бывает довольно редко - примерно 90% моих заявок исполняется. То есть несколько десятков раз в сутки, а то и того меньше. Шастать же по таблице сделок элементарно невыгодно: сделки могут происходить и несколько раз в секунду, и здесь нужно именно прерывание, в котором уже ничего искать не нужно, а только быстренько обработать готовое событие. Скрипту и без того есть чем заняться: он принимает решения о новых сделках, он мониторит рынок, считает и анализирует свечи разных таймфреймов, он рисует всю эту фигню на экране (если не установлен "спящий режим"), а обслуживать сотни или тысячи тикеров не так-то просто. Ему тупо НЕКОГДА ползать ещё и по таблице сделок, в которой непонятно когда и как обновляется информация. Сделка совершена - всё, забыли про неё - она уже обработана! А таблица с течением времени только пухнет, данные там тоже недостоверные, да ещё и всё более затратный поиск. Нафиг нужно такое счастье?

swerg, Меня прям умиляют эти распальцованные неучи. Кто тебе сказал, придурок, что я не понимаю разницу между транзакцией и заявкой? И с какого бодуна ты корчишь из себя учителя? Ах, он "подробно расписал", панимащ! А я тебя об этом спрашивал? Как только увидят знакомое слово, так тут же начинают пытаться изобразить из себя что-то состоятельное. Тьфу на вас!
Отладка QUIK 8.13
 
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, повторяться лень, так что если интересно, покопайтесь в моих сообщениях. Коротко: я считаю этот вариант самым оптимальным.

Я?! Это он на меня наезжает. Далеко не первый раз, кстати. Камикдзе...  :smile: Кстати, что за "существенную информацию" он умудрился сообщить? Лично я кроме словесного поноса на грани истерики ничего не заметил.
Отладка QUIK 8.13
 
swerg, Лапуль, ну не надо пороть ахинею с умным видом. Ежу понятно, что информация от биржи поступает в произвольные моменты времени. И я уже давал пару раз предложение, чтобы они сначала накопили все необходимые данные, а уж потом вызывали коллбеки скрипта, ибо несколько прерываний на одно событие есть маразм. И мне совершенно по барабану, что там куда и откуда приходит - я передавал заявку в терминал, и единственное, что знаю я и что обязан знать он - это идентификатор моей транзакции. И я здесь уже писал, что в большинстве случаев, то в ontrade приходит сразу полная информация, включая указанный пользователем ID транзакции и спрашивал, что делать В МЕНЬШИНСТВЕ. И при чём тут сервер Квика? Прерывание вызывает терминал, которому прекрасно известен ID транзакции. За каким хером пользователю нужен этот коллбек, если он в принципе не может определить, по какой именно заявке скрипта он пришёл? И ещё писал, что практически всегда приходят ТРИ прерывания на одно событие и что изредка бывает так, что НИ ОДНО из них не содержит правильных данных. И это есть именно ОШИБКА.
Отладка QUIK 8.13
 
swerg, Лапуль, именно нестабильно проявляющиеся ошибки и есть самые сложные для обнаружения - это тоже азбучная истина.
Отладка QUIK 8.13
 
swerg, Лапуль, да я в тыщу раз лучше тебя знаю, "как оно на самом деле". Азбучные истины, подаваемые за плод "очень глубокого многолетнего изучения". А ты вместо того, чтобы что-то ПО ДЕЛУ сказать, продолжаешь выпендриваться по-идиотски. Дурак и напыщеный идиот.

Лапуль, я же русским языком сказал, что мне НАСРАТЬ на инфу с сервера - мне нужна правильная информация по МОИМ заявкам, и если эта придурь вместо МОЕЙ ID транзакции подсовывает 0, то это глюк ТЕРМИНАЛА! От него и не требуется "производить содержательной работы со сделкам и заявками" - мой скрипт прекрасно с этим справляется. Сейчас вот вообще всё обложил отладочной печатью, а эта сволочь перестала ошибки давать - ошибка нестабильная. Да ещё и на бирже паника - Газпром грёбнулся почти на 30%. Вроде как золотое время, чтобы всласть порезвиться скрипту, но я лучше подожду - и так количество сделок за полтыщи перевалило - никогда такого не было, а у меня непонятный глюк висит.
Отладка QUIK 8.13
 
swerg, Лапуль, Вы где-нибудь у меня видели хоть полсловечка на тему, что "прерывания, как я их называю" (а OnTrade - это именно прерывание) приходят НЕ в любом порядке? А хоть полсловечка на тему, что я отправляю не транзакцию, а заявку? Там открытым текстом для особо одарённых указано, что это именно транзакция, нулевое поле элемента стека прерываний. И при чём тут "сервер квика"? ТЕРМИНАЛ Квике получает информацию ОТ МОЕГО СКРИПТА информацию о заявке! А уж зарегистрирована она или нет - это ЕГО проблемы, а не мои. Я ВААПЩЕ НЕ ПОЛЬЗУЮСЬ OnOrder.

Да, согласен: "смешно читать про такие наивные "открытия" пальцегнутого балбеса. Это сразу с головой выдаёт его реальный уровень". С зеркалом разговорились, лапуль?
Отладка QUIK 8.13
 
Старатель, Кстати, да - ошибка моя (по поводу одинаковых значений всех полей) - вот код
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");
В заголовках скопированный нолик поправил, а в самих значениях забыл. Но это не отменяет того факта, что сделки ТЕРЯЮТСЯ, несмотря на то, что прерывания по ним ПРИХОДЯТ. И эта ошибка никуда не исчезла - моя оказалась всего лишь в выводе
Беспрерывная робота робота, Как сделать так, чтобы робот был постоянно в работе и обрабатывал каждый тик?
 
БорисД, Боря, я же тебе говорил: есть железобетоннейший, надёжнейший и объективнейший критерий: размер кошелька. В смысле, скорость его изменения. И это единственно правильный способ оценки в жизнеспособности любых стратегий.

P.S. Я никогда ничего никому не запрещал и не отказывался что-либо обсуждать. Просто результаты говорят сами за себя. По тому самому критерию.
Отладка QUIK 8.13
 
Старатель, Исходя из представленного кода, НЕ ТОЛЬКО "в 4-м параметре не может быть нуля от слова совсем". Его точно так же не может быть от того же самого слова и в других полях тоже: в 0-м должно сидеть trans_id, в 1-м - order_num, во 2-м - trade_num, в 3-м - sec_code, в 5-м - qty, в 6-м - price. И в 99 случаях из 100 они именно там и сидят. И это ЕДИНСТВЕННОЕ место в скрипте, когда в стек что-то ПИШЕТСЯ. Читается - да, в другом месте, в обработчике по таймеру, но, во-первых, там ЧИТАЕТСЯ, а во-вторых, даже если там и были нули, в следующем прерывании, как правило, сидят уже корректные данные, и данные эти готовлю НЕ Я - ни в случае ошибок, ни в каком-либо другом случае. Кстати, когда я впервые обнаружил этот 0 вместо ID транзакции, в остальных полях сидели ПРАВИЛЬНЫЕ значения. Более того: если ХОТЬ В ОДНОМ из трёх прерываний приходят верные данные, сделка корректно обрабатывается. В-третьих, к элементам стека сделок я не прикасаюсь ВААПЩЕ - я даже не уничтожаю этот элемент стека после обработки - должен же и сборщик мусора чем-то заниматься. Наконец, я уже не раз писал, что четверть, если не треть моего кода написана исключительно с целью компенсации глюков системного софта Квика, коих тут просто НЕМЕРЯЯНО, и от версии к версии положение всё ухудшается. В данном случае сделки ТЕРЯЮТСЯ, а теряться они НЕ ДОЛЖНЫ. Я не бог, я могу и ошибаться, но "рукожопость" здесь, как минимум, НЕ ТОЛЬКО у меня.
Отладка QUIK 8.13
 
Вдогонку к предыдущему моему сообщению https://forum.quik.ru/messages/forum10/message63758/topic6356/#message63758. Ситуация оказалась куда более неприятной, чем я предполагал.

Вот полный код моего обработчика:
Код
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 транзакций, только правильные - это я их формировал. Повторяю: это фрагмент лога один неполный день торгов! Не кажется ли вам, что ошибок, мягко говоря, до хрена? И у меня снова фантазии не хватает, как можно написать софт, который способен вытворять ТАКОЕ. И что прикажете делать? Тем более, что функция сверки портфелей тоже глючит.
Беспрерывная робота робота, Как сделать так, чтобы робот был постоянно в работе и обрабатывал каждый тик?
 
nikolz, Чо за истерика, лапуль? Я вообще не понял, что Вам от меня надобно. Какие ссылки? Какие числовые данные? Какие мои достижения? Всё Вам было разжёвано предельно конкретно.
Уничтожаем фейки
 
nikolz, Чайники собираются бороться с чайниками? Это круто! Ха-ха-ха! Так это со мной чайник собрался бодаться? Ну, флаг в руки... :smile:

Фейк №1
Есть тики, есть обезличенные сделки - и то, и другое для торговли нафиг не нужно, вне зависимости от того, разные это вещи или одно и то же. Соответственно, все эти способы их получения и прочие "тесты" есть никому не нужный онанизм. Приговор окончательный, обжалованию не подлежит.
Страницы: Пред. 1 ... 8 9 10 11 12 13 14 15 16 17 18 ... 41 След.
Наверх