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

nikolz, Лапуль, Вы вообще читаете, что я пишу? Я говорил О СДЕЛКАХ, а не о заявках. У меня, например, более 90% заявок исполняются. Думаю, даже более 95%. Это во-первых. Во-вторых, если "скрипт по 36 акциям за час выставил и снял 64 тысячи заявок", то это ИДИОТИЗМ. Но тут ещё и вопрос: он просто ставил и снимал заявки или ещё и ОТСЛЕЖИВАЛ их? Ведь на каждую такую заявку приходит целая колода прерываний, и при тех цифрах их количество должно быть 30-50 в секунду, если не больше. Как дубли ловить будем? Или хрен бы с ними - главное послать, а там хоть трава не расти? А вот если Вы будете обслуживать свои заявки, то Квик СДОХНЕТ! АДНАЗНАЧНА!

И что с того, что "сейчас на бирже несколько тысяч инструментов"? У Финама, кстати, несколько ДЕСЯТКОВ тысяч. А лично меня интересует лишь несколько сотен. А подавляющее большинство участников этого форума (полагаю, включая лично Вас) и того меньше: несколько десятков или даже несколько штук. Что сказать-то хотели?

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

Nikolay, Убей, не понимаю, зачем нужно искать на свою жопу приключений.  Посмотрим на постулаты (ну или гипотезы):
1. Скрипт непрерывно работает часами (или даже днями, неделями).
2. Всё время, пока он работает, он мониторит состояние рынка, портфеля, кошелька и т.п.
3. В любой момент своей работы он может послать заявку на совершение сделки - с тем тикером и по такой цене, которая его устраивает здесь и сейчас.
4. Количество сделок, которые скрипт совершает в сутки, может варьироваться от единиц (при такой частоте, собссно, скрипт вообще не нужен) до десятков тысяч (при сотнях Квик наверняка сдохнет, да и при десятках спорный вопрос), т.е. допустимый диапазон десятки-сотни-тысячи сделок в сутки.
5. Количество ошибок при сделках в сутки (по любым причинам) может исчисляться ну никак не больше, чем единицами (иначе такой софт нужно просто выбросить на помойку), а потому интервалы между процедурами выявления таких ошибок должны составлять минуты, десятки минут, часы, но никак не секунды.
6. Чем позже принимается решение о сделке, тем (потенциально) у скрипта больше информации для его принятия.
7. Чем позже исполняется принятое решение о сделке, тем больше вероятность, что ситуация изменилась, и это решение уже устарело, что оно не было бы принято в тот момент, когда заявка исполнилась.
Вопрос: ТАК ЗА КАКИМ ХЕРОМ заниматься всем этим онанизмом? Что, трудно сбросить к чертям собачьим все открытые заявки при остановке или включении скрипта? Или посылать заявки именно тогда, когда скрипт посчитает нужным их совершить? У меня 90% заявок исполняются в течение нескольких секунд, а не исполненные снимаются через 3 минуты активности - всё, поезд ушёл, решение устарело! Зачем искать на свою жопу приключений? НЕ ПОНИМАЮ!

just, Никак. В смысле, из таблицы orders - никак. Но можно отслеживать их количество самим скриптом. Например, мой скрипт ведёт свой собственный стек активных заявок (точнее, не активных в смысле торговли, а ещё не обслуженных самим скриптом), и его размер сразу говорит об их количестве.  

Konstantin, Коллбек содержит sleep?! Это же самоубийство!  

nikolz, А что тут обосновывать? Ещё во времена моей молодости было какое-то исследование, что задержка реакции на действия пользователя свыше 5 секунд вызывает раздражение, свыше 15 секунд - нервные расстройства. С тех пор темп жизни ускорился, процессоры стали круче в тысячи раз, и любая задержка просто недопустима. Полсекунды - та самая граница, до которой юзер задержки не замечает и считает реакцию на свои действия практически мгновенной.

Я не торгую по 1000 инструментам - у меня на это денег нет. Я слежу за 1000 инструментами, а в портфеле у меня болтается несколько десятков (обычно в районе полтинника).

Лапуль, кто Вам сказал, что я "на один инструмент Вы трачу не менее 0.5 секунды сна + время обработки"? Я опрашиваю инструменты раз в секунду, но всю 1000 инструментов сразу. И нет проблем! Кое-где в этот момент принимаются решения на покупку или продажу, но это обычно лишь несколько десятков или сотен действий в сутки.

nikolz, Использование sleep - ЛУЧШЕЕ решение! Простое, отлаженное, работающее, эффективное. Не sleep (1), конечно, а sleep (500). Использовать меньшие задержки в скриптах для торговли не вижу ни малейшего смысла. А если нет диалога, то и вообще sleep (1000).

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

Nikolay, Не помогут.  

Айдар, Чисто алгоритмически сдвинуть массив без цикла проще простого: это либо вставка элемента либо его удаление. Если массив не отсортирован по какому-либо признаку, то добавлять новый элемент нужно всегда в конец, а при удалении текущего ставить последний элемент на его место и уменьшать размер массива на единицу. Если же требуется поддерживать существующую сортировку, без цикла обойтись невозможно. Точнее, невозможно, если данные организованы именно в виде массива, а не списка - там достаточно поправить нужным образом указатели.

Код не смотрел, но глаз сразу зацепился за OnAllTrade. Насколько я помню, это прерывание, причём очень глючное и страшно тормознутое, так что внутри него ваапще ничего делать категорически нельзя (а лучше не использовать вообще).

nikolz, Лапуль, сколько раз можно повторять, что Вы и есть самый натуральный, без подмесу, чайник? И что профессионалу почти всё равно, на каком языке писать - была бы обеспечена требуемая функциональность.

Как всегда, уже постановка задачи бездарная до невозможности:

Есть ГРУППА инструментов X и их параметров P, причём набор параметров для разных инструментов и/или их классов может различаться и в таблицу не влезать - только в ГРУППУ таблиц. А "искать параметры конкретного инструмента X в этой таблице" нужно только В ИСКЛЮЧИТЕЛЬНЫХ случаях - при нормальной организации должно быть и так известно, где они лежат.
Ответ: обратиться к нему по имени (лучше по индексу). А всю остальную бредятину выбросить на помойку. И тогда значение любого параметра просто достаётся из этой таблицы: V=T[X][P][a][b][c]

Да, бывает и так, что используется НЕСКОЛЬКО индексных массивов, в которых под одинаковыми номерами j пишем некие данные. Например, у меня аж ВОСЕМЬ таких массивов по ДЕВЯТИ таймфреймам для каждого из пары-тройки сотен или тысяч обслуживаемых инструментов. Это свечи (накапливаемые, последние и предпоследние), ранги скоростей движения курса, количество сделанных ставок на каждом таймфрейме и ещё кое-что. И обращение к ним одинаковое, лапуль, тупее не придумаешь. Например, в ячейке a[i][1][4][j] лежит размер массива сделанных ставок по i-му тикеру на j-м таймфрейме. И искать ничего не надо, подходи и бери. А криворукие бездари пущай перебирают в цикле свои "вариант 1" и "вариант 2" - что с них взять, кроме анализа?

nikolz, АХХХРЕНИТЕЛЬНЫЕ "числовые данные", лапуль! Предположим, что 800 000 клиентов, предположим, что 100 серверов, предположим, что все одновременно заявки послали. Что ни предположение, то БСК.

Вот именно: мало ли что на заборе пишут. В смысле, в ФЗ.

В любом случае "реальное время" у робота на клиенте нужно измерять В СЕКУНДАХ, а не в МИЛЛИсекундах и не в МИКРОсекундах.  Шурупен зи?

nikolz, Чушь полная.

1. Вероятность того, что все клиенты одновременно выставляют заявки РАВНА нулю.

2. Даже в этом случае данные от клиентов обрабатываются последовательно, и очередь (системная) одна: даже просто для того, чтобы раскидать пакеты по серверам, нужно принимать какие-то решения на уровне диспетчера, даже если эти решения принимаются на аппаратном уровне.

3. Заявка клиента будет стоять в очереди до тех пор, пока не будет исполнена или снята, а никакие не "8 секунд". Если же под "заявкой" подразумевается любая транзакция, то время её обработки наверняка будет зависеть от её вида.

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

5. В любом случае "реальное время" у робота на клиенте нужно измерять В СЕКУНДАХ, а не в МИЛЛИсекундах и не в МИКРОсекундах. Dixi.

TGB, Лапуль, Вам известно слово "сарказм"? Пишется "безумная сложность", а произносится "НУ ЧТО ТУТ ВАЩЕ МОЖЕТ БЫТЬ СЛОЖНОГО"?! Когда-то здесь какой-то придурок (николз, кажется) говорил, что торговый робот сложнее шахматной программы.

И утомили Вы меня своими дурацкими "функциями сереализации". Тупейший вопрос: НУ ОТКУДА, ОТКУДА, ОТКУДА этим долбаным функциям знать, что НУЖНО сохранять, а что сохранять НЕ нужно? Мне плевать, чем там "вполне обходитесь Вы" - я всего лишь говорю, что Ваши убогие функции нафиг никому не нужны, их место на помойке.

TGB, Ну что мне, ликбез проводить? Вы же явно себя учеником не считаете. Ладно, ещё разок попробую.

1. Капс всегда был и остался способом выделения фрагментов текста. Иногда единственным (например, в Фейсбуке). Так что "это похоже" именно на выделение фрагментов текста, чем мой капс и является в действительности.

2. А при чём тут "технологические сложности"?  Сам язык убог до неприличия - даже тип integer отсутствует. Я говорил про беспомощность Ваших функций, которые, как я предполагаю (в код я не заглядывал и не собираюсь) способна сохранять Lua-таблицы (которые ничего общего с таблицами не имеют) или дерево, которое эта структура может образовать. Уже в моём третьем сообщении на этом форуме... нет, вру - в четвёртом от 29.09.2020 10:31:16 я писал:
Ну вот, по Вашей ссылке, первым же предложением: "Tables in Lua are not a data structure; they are the data structure. All structures that other languages offer---arrays, records, lists, queues, sets---are represented with tables in Lua". Иными словами, никаких структур данных просто НЕТ! Печально... А уж "обоснование" и вообще курам на смех: "Хотя мы МОЖЕМ (!) реализовать массивы и списки, таблицы мощнее. Многие алгоритмы упрощаются до тривиальности с использованием таблиц". И дальше вообще издевательство: "Например, вы редко пишете поиск в Lua, потому что таблицы предлагают прямой (!!!) доступ к любому типу". Ребятки, доступ по ключу - это не прямой, а как раз КРИВОЙ доступ к данным! Даже если обозвать ключи "индексами". Уши бы надрать этому "Роберто Иерусалимскому!
В общем, с языком почти всё ясно: граф (точнее, дерево) объектов построить можно, а простейшую таблицу или даже массив - нельзя. Остаётся разобраться со строковыми переменными: способна ли эта loadstring интерпретировать строки как операторы языка (или, скажем, функции), то есть имеется ли здесь техническая возможность программирования данными.

3. Я вообще не говорил никогда про стратегию торгов - по крайней мере, про её сложность. Стратегии торгов достаточно простые - все до единой. По крайней мере, если для них сложность не самоцель, а задачей является эффективность стратегии. Да и откуда взяться сложности? Курс может либо расти, либо падать, либо стоять на месте, либо вообще торги по тикеру не ведутся - И ВСЁ! Больше даже вариантов никаких нет - просто безумная сложность!   Я говорил про сложность СТРУКТУРЫ данных, ЛОГИЧЕСКОЙ структуры, и предельная сложность такой структуры называется "граф общего вида" (если учесть, что узлами такого графа могут быть не только атомарные элементы, но и субграфы, а его рёбра также могут быть нагружены произвольной информацией, при этом количество рёбер по разным измерениям может быть переменным, в т.ч. нулевым.

4. Разумеется, "это не так". Единственно возможная структура на Lua представляет собой дерево, а обращение к её элементом конструкциями языка выглядит именно как обращение к ячейкам многомерного куба. Так что никакой "матрицы" нет и в помине. Более того, я терпеть не могу эти матрицы, и их нет вообще ни в одной из разработанных мною программ - я чуть ли не всю свою сознательную жизнь интересовался именно СЛОЖНЫМИ данными, а не этими погремушками.

5. Сложность данных не имеет ничего общего со сложностью типов данных - атомарные элементы (а никакие не "таблицы") могут быть любых типов, а в сохранённом виде это вообще одни только строки. Это ничуть не мешает построению из таких элементов конструкций ЛЮБОЙ сложности.

6. Вот именно: "надо стремиться к простоте". Не городить уродливую и беспомощную "универсальную" конструкцию, а делать простейшими способами то, что нужно. А нужно (мне) сохранить часть переменных (просто переменных или массивов, или деревьев) в файл - и не всех, которые там вообще есть, а те, которые мне НУЖНО сохранить. Сохраняются даже те данные, которых в структуре вообще нет - они рассчитываются "на лету" перед записью. И восстановить мне нужно не все данные, а те, которые мне НУЖНО восстановить, разбросав их по разным переменным, массивам, таблицам, деревьям. Вот и вся задача! И выполняется она в main (при запуске скрипта), в OnStop (по выходу), да раз в 5 минут (по таймеру) на всякий пожарный. Хоть сто лет думайте - ничего более простого не придумаете.

7. Да, все данные по тикерам сидят именно в этой "корневой" таблице - это тоже самое простое и самое разумное решение. Переменная эта, разумеется, глобальная, так что все эти данные всегда доступны из любой функции.

8. Господи, НУ ЗА КАКИМ ХЕРОМ нужно "сохранять и восстанавливать ВСЁ окружение"? Это же ИДИОТИЗМ! Нужно делать только то, что нужно, и ничего, кроме этого.

TGB, Пока?! Сколько можно повторять, что структура моих сохраняемых и восстанавливаемых данных НАМНОГО сложнее, и эта задача В ПРИНЦИПЕ не решаема такими функциями. Я не говорил, что эти функции не работают - я говорил, что они беспомощны в сколько-нибудь сложных случаях. Мне плевать, чужое это или своё - в любом случае такие функции практически бесполезны. И ещё больше плевать, какие там у Вас "возникают ощущения" - это Ваши комплексы, не мои. А про "мой непревзойденный скрипт" здесь знает разве что Борис, и никто более - я вообще про него практически ничего не говорил, кроме самых общих "технических" вопросов.

Да чего Вы ко мне прицепились? Не хочу я на Ваш код смотреть! Вообще не хочу, он алгоритмически убог, уже на стадии постановки задачи.

TGB, Я не вижу смысла в этих функциях - зачем же мне их тестировать? У меня для тестирования великое множество других, и даже связанных с торговлей, хотя алгоритмы торговли довольно просты, и проблемы там, в основном, связаны с глюками софта самого Квика - например, та самая синхронизация. Но есть и в тыщу раз более интересные задачи.

TGB, А у нас что, «батлз»? И я тыщу раз говорил, что я никогда не смотрю на то, КТО сказал - только на то, ЧТО сказано. Вы меня не интересуете, от слова "совсем", так что комментировать Вас я не собираюсь. Но если снова начнёте пороть чушь, ничего хорошего я Вам не гарантирую.

TGB, Да объяснял уже тыщу раз: "лапуля" - это термин такой, многократно доказавший за долгие годы применения свою высочайшую эффективность в вытравливании головожопых - они на него клюют, как на опарыша. И одновременно индикатор, что я уже не испытываю к собеседнику никаких чувств, кроме презрения. Вот именно, здесь форум по программированию, а не реклама маразматического софта как очередной вундервафли.

Лапуль, я уже затрахался торкать Вас носом, что сохраняется НЕ ВСЯ таблица, что сохраняемая структура в файле СОВЕРШЕННО ДРУГАЯ, нежели структура в ОЗУ, что восстанавливаются НЕ ВСЕ данные, что часть из них исполняется как операторы языка, что никакая универсальная утилита В ПРИНЦИПЕ не может этого сделать, что это не "таблица произвольной вложенности" и даже не дерево, а граф общего вида. Или, если Ваши мозги ничего кроме таблиц воспринимать не способны, это МНОЖЕСТВО таблиц, у которых ЧАСТЬ полей восстанавливается, а другая часть инициализируется значениями по умолчанию или читается из каких-то других источников. А "предложенные Вами коды можете засунуть себе в задницу - я вообще не могу представить, кому и за каким хреном это беспомощное дерьмо может понадобиться.

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

TGB, Лапуль, я и сам по себе хороший алгоритмист, и как таковой, знаю совершенно точно, что эту задачу никакая "универсальная" утилита В ПРИНЦИПЕ неспособна выполнить, какая бы хрень по этому поводу ни была где-либо написана кем бы то ни было. И я Вас уже торкал носом в этот Ваш коммент. Можем повторить(с):
НИКАКАЯ долбаная "сереализация" В ПРИНЦИПЕ неспособна это сделать! Хотя бы по той простой причине, что она не знает и не может знать, что и как сохранять, в каком виде, как и куда это всё восстанавливать. Она не будет работать НИКОГДА!

swerg, Блин, и первым же предложением "The table type implements associative arrays"! Лапуль, это не просто дебил, это КЛИНИЧЕСКИЙ дебил! Как и все, кто его читает.  

swerg, Лапуль, документацию, в которой таблица является типом данных, нужно относить на помойку, не читая.   Кто эту бредятину написал? Вы, что ли? Ах, Роберто Иерусалимский? Дык я чуть ли не в первом своём комменте на этом форуме говорил, что он дебил. Когаловский Михаил Рувимович - вот этого человека стоит читать, а не всяких придурков.

TGB, Да и я примирительно. Ну, сказали глупость - с кем не бывает?   И кто Вам сказал, что я злюсь? Я всего лишь сказал, что Ваше беспомощное дерьмо НИКОГДА оно не сделает из того, что требуется. И это просто медицинский факт.

Естественно, Вы нигде не писали, что сереализация знает что и как сохранять - я бы Вас высмеял беспощадно. НА КОЙ мне эти дурацкие функции tbl_to_string и string_to_tbl, если они по определению нихрена не умеют? Тем более, что весь код моего парсера и сохранения короче кода Ваших функций, которым вне зависимости от этого место только на помойке. НЕ МОГ БЫ я "заменить весь свой код по сохранению и при необходимости восстановлению моего графа двумя строками"! НЕ МОГ! Я же русским языком сказал, что при восстановлении подавляющее большинство всех этих данных теряют актуальность и НЕ ДОЛЖНЫ восстанавливаться! И что транспортный формат данных отличается от рабочего, И ДОЛЖЕН от него отличаться. И что часть данных предназначена для человека, и это не копия какого-то куска таблицы, а, в большинстве своём, РАСЧЁТНЫЕ данные, и что при восстановлении такие данные должны игнорироваться. Могу добавить, что есть ещё часть данных, которые записываются в синтаксисе языка Lua, и при восстановлении никуда не восстанавливаются, а просто исполняются как операторы языка (через loadstring). Так на кой мне (или кому бы то ни было) Ваше беспомощное дерьмо? НИКОГДА оно не сделает из того, что требуется. НИКОГДА!  

TGB, О, Господи!

КАКАЯ, блин, "таблица преобразовалась в КАКУЮ строку"?! Часть таблицы Lua (ЧАСТЬ, а не вся таблица!) преобразуется ВО МНОЖЕСТВО строк, файла, причём их структура РАЗНАЯ. Эти строки содержат информацию о рынке, о портфеле пользователя, о самом пользователе (код клиента, номер счёта и т.д.), о его сделках, текущей прибыли/убытку по тикерам, информацию по свечам, размер лота, ранги скоростей движения курса по таймфреймам, информацию о незакрытых заявках и прочая, и прочая, и прочая. Подавляющего большинства этих данных в файле дампа просто НЕТ, их НЕЛЬЗЯ сохранять и восстанавливать, ибо к моменту восстановления там будут ДРУГИЕ значения. Сохраняемых и восстанавливаемых данных там не более 10-20% от общего их количества, и они имеют СОВСЕМ ДРУГУЮ структуру. Мало того: туда записывается информация для самого пользователя, вроде отчёта о текущем состоянии портфеля по всем сделанным ставкам. НИКАКАЯ долбаная "сереализация" В ПРИНЦИПЕ неспособна это сделать! Хотя бы по той простой причине, что она не знает и не может знать, что и как сохранять, в каком виде, как и куда это всё восстанавливать. Она не будет работать НИКОГДА!

TGB, Это Вы "читайте внимательно" - не только ТОТ пост, который процитировали, но и самый первый в ветке. И там не "из контекста можно понять", а открытым текстом сказано, что и как. К тому же "таблица как ТИП ДАННЫХ" есть идиотизм. И кто Вам сказал, что "элементарный код я представляю как ваше открытие"? Это утверждение не соответствует действительности, а потому отвечать на вопрос "зачем" относительно лживого утверждения не имеет смысла. А Ваши "сильные подозрения" меня не интересуют.Зачем мне "пробовать"? Любому дебилу понятно, что исходная и сохраняемая структура - это РАЗНЫЕ структуры. Или не любому?

TGB, Я так и сказал: "Зачем просто, когда можно сложно?"   Задача организации торговли элементарна, возможности языка ничтожны, глюков предостаточно, и лично я ещё до того, как написал свою первую строчку на Lua, знал, что буду использовать в качестве имён именно числовые индексы, и много раз здесь советовал поступать так же и писал, почему.

Здесь, кстати, вообще сказано, что нужно сохранять таблицу, созданную по AllocTable, т.е. таблицу Квика, а не таблицу Lua, и потому доступ к её данным должен осуществляться чем-то вроде getItem, так что никаких "таблиц произвольной вложенности, в которых индексами-ключами могут быть таблицы" там нет по определению.

Да, мой код не обработает ИДИОТСКУЮ таблицу: t = { [‘Тикер’] = 'SBER'}. А вот НОРМАЛЬНУЮ таблицу тот же код записи дампа прекрасно обрабатывает тем же способом, причём выводит не таблицу, а именно граф. Пара фрагментов РЕАЛЬНОГО кода записи этого всего в файл:

for i=1,N do -- цикл по тикерам
F:write(a[i][0][0].."\1"..a[i][0][1].."\2"..a[i][1][1].."\3"..d(a[i][1][2]).."\4"..d(a[i][1][3]).."\t");

Здесь выводится и код тикера, и код класса тикера, и код валюты тикера, и его качество (от "говна" до "отличного"), и его статус, где разные биты за что-то отвечают. Хранить эти данные в коде скрипта есть клинический маразм.

И далее (внутренний цикл):
while j<a[i][1][4] do -- выводим данные по сделкам
F:write(d(a[i][5][j])..":"..d(a[i][5][j+1]).."\t");
 j=j+2; -- переходим к следующей ставке

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

Парсер чуть сложнее.  

TGB, Зачем просто, когда можно сложно? На код просто смотреть страшно (и я не собираюсь этого делать). Программа пишется в 5 секунд, и она в 100500 раз проще, чем в этом "простом варианте". ЗА КАКИМ ХРЕНОМ нужна эта долбаная "конвертация таблицы в строку"? Заняться больше нечем?

Мой скрипт каждые 5 минут записывает дамп текущего состояния - так это целый граф, а не какая-то сраная таблица! Написать этот код ничуть не сложнее, чем этот пост. Вот, навскидку:Парсер чуть сложнее - пишется не в 5 секунд, а в 6.  

Дмитрий,
О, Господи!.. Теперь уже и таблица стала "типом данных"? А граф тоже, или ещё нет?

В какой файл, в каком формате? CSV (как самое простое и разумное)? Тупейший двойной цикл: по строкам и (внутренний) по ячейкам текущей строки. Ну и разделители полей и кортежей нужно вставлять, разумеется.

Евгений, Что значит "в квике нет"? Простейший if-then-else. Номера счетов скрипт знает? Заявки тоже он выставляет? Так какие проблемы?

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

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

Я думаю, что описанные здесь ошибки (attempt to compare number with nil, tonumber вернул nil и т.п.) есть именно ошибки синхронизации (подобные вещи нередко встречаются и у меня). Места возникновения этих ошибок достаточно очевидны: коллбеки и обращения к таблицам QUIK, т.е. getParamEx, getDepoEx, GetCell и всё такое прочее, причём именно get, в не set - эти ошибки мало интересны. Любая из этих тварей может в любой момент вернуть nil - иногда так, что и сам скрипт вылетит. Надежды на то, что когда-либо хотя бы часть этих ошибок будет исправлена "на стороне Квика" лично у меня нет ни малейшей, так что бороться с ними придётся "подручными средствами". Такими средствами являются:

1. Минимизация использования всего вышеперечисленного: всё, что может сделать сам скрипт, должен делать сам скрипт. В частности, настоятельно рекомендую отказаться от всех "подписных изданий" (стаканов или даже свечей) - это источник головной боли, тормозов и дезинформации. У меня из коллбеков используется только OnTrade и OnStop, каждый из которых в своё время попортил мне немало крови, а OnTrade до сих пор продолжает это делать.

2. Как можно реже обращаться к таблицам Квика. У меня это только "orders", причём обращение к ней через getItem происходит лишь в некоторых экзотических случаях снятия несработавших заявок (вряд ли больше десятка-другого раз за сутки). Кроме того, я обращаюсь (через GetCell и тоже очень редко) к своим таблицам, созданным Квиком, но только к одному из столбцов таблицы по тикерам (невидимому), только для того, чтобы определить "настоящий" ID строки, который не меняется, скажем, при изменении порядка следования строк в таблице после сортировки и только для определения, по какому именно тикеру должно быть вызвано контекстное меню.

3. Проверять на nil во всех таких "опасных" ситуациях - это, по крайней мере, не приведёт к вылету скрипта.

4. Минимизировать время работы коллбеков. Например, мой OnTrade с течением времени оброс всякими проверками до неприличия из-за маразматической и годами не исправляемой ситуации с приходом нескольких прерываний на одно событие, да ещё и вразнобой, а также необходимости учёта "левых" сделок, совершённых в обход скрипта. Похоже, здесь тоже идут какие-то наводки из-за того, что во время обработки коллбека ещё что-то происходит. Планирую максимально облегчить сам OnTrade и перенести основную обработку в прерывание по таймеру, которое фактически находится в потоке main.

5. Очень аккуратно относиться к программированию диалога, средств для организации которого в Lua практически нет. Я толком не понимаю, что там происходит в обработчиках, устанавливаемых по SetTableNotificationCallback, но тут иногда даже не скрипт вылетает, а сам Квик отвисает.

Ну и не обращаться к техподдержке с пожеланиями что-либо исправить: в лучшем случае, останется всё как есть.  

Дмитрий,Сюда посмотрите: https://forum.quik.ru/messages/forum10/message61995/topic6503/#message61995

БорисД, Это не стакан, Борь, это ТТТ, т.е. на несколько порядков более быстрый способ. Стакан идеологически примерно та же хрень, как и со свечами: подписаться на него и Квик сам будет как-то менять там данные. И если даже со свечами работать практически невозможно (а свечи меня интересовали от 15 минут и выше!), то в стакане информация меняется тоже на несколько порядков быстрее. Так что по ТТТ за бид и аск следить можно и при паре тысяч тикеров, и при большем их количестве, а за стаканами или даже за свечами следить нельзя и при десятках, если не единицах - даже если не принимать во внимание бесконечные глюки Квика - только его тормоза. Тем более, что частота сделок у тебя намного выше, чем у меня, и я хочу её замедлить, чтобы сделки совершались не чаще, чем раз в секунду.

Вася, Объясняю по пунктам:
1. И по Вашему собственному признанию, и по задаваемым здесь вопросам, Вы новичок в программировании, а здесь требуется уровень СУПЕРпрофессионала.
2. Мне совершенно наплевать на все эти '[Un]subscribe_Level_II_Quotes: во-первых, для принятия решение о сделках стакан практически бесполезен. Более того, он частенько используется именно в качестве разводки для лохов. Во-вторых, информация в стакане меняется очень быстро, и любыми своими "подписками и отписками" Вы безнадёжно теряете время. В-третьих, если "вопрос скорости обработки в этой задаче не критичен", то у меня просто фантазии не хватает, за каким хреном Вам понадобился стакан. И не 2000, а хотя бы один.
3. Если Ваша задача "выполнить функцию", а не "получить достоверные данные", то - извиняюсь - задача выполнима.    

Вася, Справиться с этой проблемой невозможно никак. Даже если у Вас будет десяток стаканов. А обслуживать 2000 тикеров не так просто даже моему скрипту, у которого ни одного стакана нет, не было, и не будет (Борис, слышишь меня? ). Ваша же задача просто безнадёжна, в принципе невыполнима.

TGB,  Я горячился очень давно и очень недолго - когда думал, что техподдержка заинтересована в качестве ПО QUIK. А у них задачи совсем другие: засрать софт любым говном, которое под руку попадётся, желательно глючным, и хорошенько это дело палкой перемешать. И я давно уже использую лишь АБСОЛЮТНО необходимые для торговли утилиты: OnTrade (тоже с дебильной, позорнейшей реализацией с колодой прерываний на одно событие), getParamEx, sendTransaction и ещё что-то. И я утверждаю, что пользоваться CalcBuySell и тому подобным говном может только полный идиот, ничего не понимающий в программировании. Приговор окончательный, обжалованию не подлежит.  

TGB, Мне АБСОЛЮТНО плевать, что там "его программа проверяет" - это ЕЁ проблемы. Мой же скрипт САМ проверяет свою состоятельность, и он при этом НЕ лезет в мой кошелёк - он имеет ту сумму в своём распоряжении, которую Я ей дал, и эта сумма может довольно заметно отличаться от содержимого моего кошелька, причём как в ту, так и в другую сторону (при маржинальной торговле). Мне НАСРАТЬ на "лимиты брокера" - в крайнем случае, он просто не пропустит мои заявки. Разумеется, "мои лимиты могут изменяться при выполнении заявок" - МОЙ скрипт это прекрасно учитывает при срабатывании OnTrade. И в гробу я видел эту идиотскую CalcBuySell, равно как и "обработку ситуации отказа выставления заявки" - просто OnTrade не сработает, И ВСЁ!

nikolz, Я сие могу объяснить.

1. Про функцию CalcBuySell первый раз слышу. Может, где и попадалась, но глаз проскальзывал мимо, ибо само название говорит, что это чистейший БСК.

2. Глянул в Гугл: "Функция предназначена для расчета максимально возможного количества лотов в заявке". ЧАВО???!!! Во-первых, за каким хреном мне нужно МАКСИМАЛЬНО возможное количество лотов в заявке? Во-вторых, откуда какая-то внешняя хреновина может знать, сколько МНЕ нужно лотов в МОЕЙ заявке?!

3. Смотрю формат вызова:  CalcBuySell(class_code, sec_code, client_code, account, price, is_buy, is_market). Что за бред?! А деньги-то где?! Да вы что, СОВСЕМ ОХРЕНЕЛИ?! Эта падла что, самостоятельно лезет в мой кошелёк, штоле? Да какое её собачье дело сколько чего там лежит?! И что, она думает, что я угроблю все свои деньги на одну-единственную сделку одного-единственного тикера?! Блин, да НАСРАТЬ, что и как она там считает, правильно или неправильно! Пользоваться этим дерьмом может только КЛИНИЧЕСКИЙ дебил!

Господа, вы ХОТЬ ЧТО-НИБУДЬ способны САМИ посчитать, СВОИМ СОБСТВЕННЫМ кодом, БЕЗ этих идиотских библиотек? Неужто не только программисты, но и быдлокодеры уже все повымерли?

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

Ой, соврал - там всего лишь 100-150 тысяч лет получается.  

Kalmar, Разумеется, оно беззнаковое, ибо отрицательное число для задержки есть полный идиотизм. Тут не 32, а 64 разряда, а вместо integer используется дурацкий тип number. Ну, пусть там будет 52 бита, пусть не попало это число в зарезервированное IEEE 754 значение "Infinity" - всё равно любое "нормальное" отрицательное значение вызовет задержку далеко за 200 миллионов лет.  

О, Господи! Опять это стадо микросекунды ловит...    

Айдар, Ну так завести эти поля и обновлять их либо по прерываниям, либо чтением соответствующих таблиц.   У меня информация о сделках обновляется в OnTrade (единственный коллбек, который я использую), что творится в стакане, меня никогда не интересовало (не говоря уже про графики), а что на его границах - это BID и OFFER из ТТТ. В рабочем окне, соответственно, никогда не было открыто ни графика, ни стакана, ни таблицы сделок. Да это и технически невозможно - мой скрипт обычно отслеживает поведение нескольких сотен тикеров одновременно.

Айдар, Функции обратного вызова не имеют ни малейшего отношения к способу хранения данных - это просто прерывания. И немного найдётся способов затормозить терминал, чем использование OnAllTrade.  

Дали игрушку для идиотов - "потоки" называется. После чего это тупорылое стадо, выковыривающее проблемы на ровном месте, получило широкое поле для словесного поноса с гнутыми пальцами. Любому дебилу в XX веке было очевидно, что в прерываниях ВСЕГДА следует делать минимальные вычисления - просто потому, что это прерывания. Любому дебилу было понятно, что пытаться заниматься "ускорением вычислений" в интерпретаторе есть Бред Сивой Кобылы. Любому дебилу было ясно, что при организации параллельной работы нужно, чтобы каждый из параллельно выполняющихся процессов был предварительно ИДЕАЛЬНО вылизан. Любому дебилу было известно, что глобальные переменные НИЧЕМ не отличаются от локальных. Любому дебилу должно быть доступно, что этот самый любой дебил может САМОСТОЯТЕЛЬНО "полностью убрать из QLUA эти монстры-колбеки", что можно ВООБЩЕ НЕ ПЕРЕДАВАТЬ данные в другие потоки, которых у дебилов "может быть любое число", а у нормальных людей это "любое число" равно нулю.

О! Это правильно! Я как раз и "свёл к минимуму использование глобальных переменных в функции main". Как я уже писал, их там всего-то тысяч сто. Ну, может, двести, но вряд ли больше. А вот классов как раз нет ни одного. Ни "в луа стиле", ни  в "си стиле" - нигде. Нет, не было и не будет.

nikolz, Лично я давно достиг АБСОЛЮТНОГО быстродействия получения параметров свечи: 0.000 мкс! Ещё до того, как написал свой первый скрипт на Lua, я прекрасно знал, что вся эта "японская" дребедень АБСОЛЮТНО не нужна торговому роботу - он прекрасно умеет считать свечи сам, причём НОРМАЛЬНЫЕ свечи, а не эту хрень. И свечи ему нужны не только минутные (насколько я помню, это минимальный интервал из того, что вообще можно "получать"), и уже по этой причине "сравнение быстродействия" на ТАКИХ свечах есть клинический идиотизм. У нормальных программистов нет никаких проблем с быстродействием и на более лёгких свечах, причём не с чтением готовенького, посчитанного дядей Васей, а с самостоятельным расчётом свечей всех мастей и размеров. С самого начала мои свечи начинались с 15-секундных, но под "тлетворным влиянием Бориса" были заменены сначала на 7.5-секундные, а затем на 10-секундные. А всё остальное - это для любителей заниматься онанизмом, щеголяя при этом вумными словечками вроде "пул потоков" или "мьютексы".

nikolz, Это означает, лапуль, что "реальное время" у такого робота измеряется В СЕКУНДАХ, а не в МИЛЛИсекундах и не в МИКРОсекундах. У меня в мейне в бесконечном цикле стоит sleep (500), т.е. полусекундная задержка, но она сделана даже не для торговли - там достаточно и в разы большей, а лишь для того, чтобы пользователю реакция на его события (нажатие клавиш или клики мышкой) казалось практически мгновенной. Только для этого, лапуль! Но и с полусекундной задержкой такая система прекрасно успевает "обработать пришедшие данные до момента прихода новых". И не на ваших идиотских тестах, а в реальной торговле с десятками, сотнями и даже тысячами тикеров. И только клинический дебил может "мечтать о создании HFT робота" на Квике. Просто программировать надо уметь, лапуль, а не корчить из себя вяликого списилиста.

nikolz, Все вроде с виду в шоколаде, но если внюхаться — то нет.©

Лапуль, информация ПОЛНОСТЬЮ определяется ПРИЁМНИКОМ. Или, если угодно, "информация есть результат интерпретации данных исполнительным механизмом". И если у "механизма" в одно ухо влетает, а из другого вылетает, никакой информации нет.

Лично мне АБСОЛЮТНО насрать на все эти дурацкие миллисекунды, время реакции колбека, время сервера и всю остальную дребедень. Всё это НИКАК не влияет на алгоритмы торговли. По крайней мере, на НОРМАЛЬНЫЕ алгоритмы - например, мои. А криворукие бездари продолжают заниматься своей клинической хернёй, то бишь ловлей микросекунд, при этом они, как правило, даже с паршивым десятком тикеров справиться не способны. O tempora, o mores!  

БорисД, Видал? Это у них называется "отказ от сотрудничества". Я тебе вчера говорил, что готов написать в техподдержку, что больше не имею к ним вообще никаких вопросов и снимаю все свои обращения, но даже и написать не удалось: эту тему тоже прихлопнули.
https://forum.quik.ru/forum10/topic6503/

Sergey Gorokhov, У меня просто слов нет! Да как хотите, так и заполняйте! МОЙ ЖЕ "массив a" - это сложное разветвлённое дерево, в котором, как я уже писал, порядка 100-200 тысяч ячеек. Но в этой функции используются только ТРИ из них на тикер, и ВСЕ ДО ЕДИНОЙ я уже описал! Как говорится, "можем повторить":
a[i][0][1] - код инструмента
a[i][0][5] - количество бумаг i-го тикера в портфеле в лотах,
a[i][0][8] - размер лота

НУ ЧТО, ЧТО, ЧТО тут может быть непонятного?!