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

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

Лапуль, я неоднократно говорил, что отвечаю ЗА ВСЕ свои слова! И за сказанные более, чем за четверть века моего пребывания в Инете, и за более полувека вне его. Так что если я говорю:  "Тиковых массивов полно в Инете, но для отладки они практически бесполезны, поскольку не привязаны ко времени", значит, они ПРАКТИЧЕСКИ БЕСПОЛЕЗНЫ! Как минимум, это моё мнение, а мнения мои, как правило, очень сложно опровергнуть - тем более, недоучками вроде Вас. Ну, и что же Вам в моей фразе не понравилось? Подтверждаю каждую запятую!

Лапуль, это ВАША глупость считать, "что тики привязаны к конкретному времени их заключения на бирже" только потому, что там есть таймерная отметка. Именно по этим отметкам я и переводил тиковый массив (ПРАКТИЧЕСКИ БЕСПОЛЕЗНЫЙ для отладки) в массив секундных свечей (очень даже полезный). Я даже немного описал КАК я это делал и ЗАЧЕМ, но для Вашего уровня интеллекта... короче, не берите в голову.

И снова о терминах: я много раз писал, что свечи для меня вовсе не эта "японская" дребедень, а нормальное среднее арифметическое значения курса за интервал, т.е. ОДНО, блин, значение, а не этот идиотский "джентльменский набор", который также для принятия решений практически бесполезен. И переводил я тиковый массив, разумеется, в массив НОРМАЛЬНЫХ секундных свечей, а не этой гадости. На объём, как я уже говорил... ну да, в этой самой ветке Николаю - на них мне всегда было насрать. Было, есть и будет!

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

Лапуль, сколько раз повторять, что моя "телега" обслуживает ТЫСЯЧИ тикеров, а Ваш сраный "самолёт", в лучшем случае, ДЕСЯТКИ. Согласитесь, я имею некоторые основания считать Ваше говно "бесполезным".

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

Никита, На срочном я пока не работал, но все 100% моих заявок лимитные.

Почему "не обращается"? Раз в секунду по каждому тикеру. В ТТТ есть и LAST, и BID, и OFFER.

Никита, Так и я когда-то тики хотел использовать.   И полностью согласен: на кой выставлять отложенные заявки, если робот и так постоянно мониторит рынок? Или на кой тогда нужен робот если их выставлять.

Да, именно так: робот двигает тейк-профит и в случае опасности разворота кидает заявку на закрывающую сделку, фиксируя прибыль. А некоторое время назад я вообще перестал выставлять заявки заранее по каким-то своим соображениям профита - фантазия рынка оказалась куда круче, чем мои доморощенные представления о нём. Поэтому я очень часто продаю по биду, а покупаю по аску, т.е. дожидаюсь момента, когда эта цена меня устраивает и лишь тогда посылаю заявку. В результате практически все мои заявки исполняются в течение пары секунд, а не висят там часами, связывая свободные деньги, вероятность исполнения близка к 100%. Правда, ходят слухи про какие-то тейкерные-мейкерные комиссии за это дело: вроде как выгодно, чтобы заявка какое-то время полежала в стакане (и прибыль от этого только вырастет, и комиссия упадёт), но когда я попробовал сдвигать цену сделки всего на один шаг цены с этой целью, четверть моих заявок перестала исполняться (я снимаю неисполненные или частично исполненные через 3 минуты), и мне это дело сильно не понравилось. Так что я теперь, скорее всего, плачу эту повышенную комиссию, да и хрен бы с ней - время дороже! Более эффективных решений я не знаю, да уже и знать не хочу: существующая версия скрипта меня вполне устраивает, за исключением некоторых мелких шероховатостей.

Nikolay, Можно, но не нужно. Бориса я переубедил - он тоже хотел считать свечи через обезличенные сделки, и у него частота сделок намного выше, чем у меня (в этом не переубедил). Это тормоза и глюки, а уж обслуживать при этом хотя бы сотню тикеров - об этом можно даже не мечтать. В Квике скорость принятия решений по ТТТ максимально возможная - остальные способы дают замедление в разы, если не на порядки.

В остальном действительно, как обычно - не надо мне, не надо никому. Не мир не вращается вокруг меня, а я даю именно те варианты решений, которые именно я считаю оптимальными, чего и другим желаю. В частности, ни объёмы, ни стаканы меня не интересуют вообще. Они не приносят никому ничего и никогда, кроме тормозов и глюков - я так ДУМАЮ!(с)  

nikolz, Может, хватит безграмотные глупости писать?

Никита, Чтобы робот был постоянно в работе, нужно его запустить и больше не останавливать.   В этом случае возможны проблемы а) если упал Интернет и б) если торги прекратились. Короче, в любой момент, когда возникают перерывы в торговле у клиента, брокера, биржи или даже отдельного тикера. Поэтому скрипт должен уметь определять моменты приостановки и возобновления торгов и реагировать на них соответствующим образом.

А вот "чтобы робот обрабатывал каждый тик" делать не нужно (если, конечно, Вашей задачей не является испортить его до уровня полной неработоспособности). Тиковых массивов полно в Инете, но для отладки они практически бесполезны, поскольку не привязаны ко времени: может быть сотня тиков в секунду, а могут быть и перерывы между ними в десятки минут и более. Когда я отлаживал скрипт по историческим данным, я специально переводил тиковый массив в свечной, усредняя цену сделок, если их было несколько за секунду. В результате массив на 2 миллиона тиков превратился в массив на 6 миллионов секундных свечей. Вот с ним уже можно работать, ибо время, в отличие от тиков, течёт равномерно. То же самое в боевом режиме: тики не нужны никому и никогда, в т.ч. HFT роботам. Точно так же для торговли в Квике нафиг не нужны ни язык программирования CИ, ни интерфейсы FIX/FAST, ни размещение своего компа в дата-центре. Наконец, нынешний софт Квика вовек не позволит Вам получать все эти тики. По крайней мере, вовремя и без глюков. Да и слава богу!
 

Никита, а) невозможно б) нафиг не нужно.

Никита,  

Никита,  

Никак. Сама ТТТ и её видимая часть - это две большие разницы. Просто кликните "копировать всё" и вставьте в файл - 5 секунд всё удовольствие.

Nikita, Запятую на точку поменяйте.

Проверил на всякий случай у себя: A=-3;message("A="'..A); Всё прекрасно работает.

Nikita, Код покажите.

Nikita,  так и дать: A=-3; В чём проблема-то?

nikolz, Лапуль, ну хватит корчить из себя списилиста вяликого! Ежу понятно, что в программировании Вы никто и звать Вас никак.

Лапуль, я писал уже здесь, что программировал аж на ТРЁХ ассемблерах - БЭСМ, PDP и Intel. Кроме того, я программировал на C, Алголе, Фортране, PL, JS, даже чуток на Паскале и Бейсике. Ах, да - ещё и Lua. Может, ещё на чём-то - не помню. И говорил тыщу раз, что профессионалу ВСЁ РАВНО на каком языке писать. И долгие годы на моих глазах происходила вся эта деградация программистов до уровня полуграмотного быдла, которое уже практически ничего не соображает и надувает щёки в этом Вавилонском столпотворении языков. Лапуль, я на своём веку видел ДЕСЯТКИ программистов ВЫСОЧАЙШЕГО класса, в том числе весьма титулованных (де Конинг или Томпсон в представлении не нуждаются). А сейчас я вижу сейчас слабо отличающегося от абсолютного нуля Вас с гнутыми пальцами. Говорят, что всё познаётся в сравнении - так небо и земля! Ну какой Вы программист, лапуль? В зеркало посмотрите!

Лапуль, только КЛИНИЧЕСКОМУ дебилу могут понадобиться потоки - чисто системная конструкция - в чисто прикладной задаче - такой, как организация торговли в Квике на Lua. И что значит "разглагольствования", лапуль? Я давным-давно говорил, что мой скрипт спокойно, без напряжения, обрабатывает тысячу инструментов на достаточно дохленьком ноуте. И 10000 потянет, хотя уже и с проблемами. Да, лапуль, НИЧЕГО не надо кроме "чистого" луа, одного потока и функции main в одном скрипте! Любой нормальный программист Вам это подтвердит - не все же, надеюсь, вымерли? И Вы не поверите, лапуль - ДЕЙСТВИТЕЛЬНО приносит бабло! Вчера приносил, сегодня принёс и завтра ещё принесёт. Вот послезавтра нет - я уезжаю в гости в другой город, и запускать его в этот день не буду. А криворуким бездарям, лапуль,  не помогут никакие "современные IDE" и вся эта огромная навозная куча языков программирования.  

Денис, Я в своё время поступил просто: добавил в ТТТ всё, что там вообще есть, столбцы "код класса" и "код инструмента" (firm_id и client_code не имеют значения), скопипастил всё в файл, отрезал всё ненужное и вот уже почти два года пользуюсь.

Вчера и сегодня поймал редко встречающуюся ошибку в прерывании OnTrade. Не только редкую, но и давно компенсированную "заочно" кодом моего скрипта. Ошибка такая: в данных от прерывания приходит нулевое значение trans_id. Поскольку прерывания приходят пачками, а ошибка редкая, то одно из них скорее всего будет обработано, второе отловлено как дубль и проигнорировано, а это интерпретировано как "сделка по левой заявке" (у меня такие сделки тоже игнорируются). Но, господа, это же МОЯ айдишка, это НА МЕНЯ возлагается обеспечение её уникальности, так какие могут быть нули? Откуда им взяться? И это на 146% ошибка именно ПО Квика - ни брокеру, ни бирже до моей айдишки нет никакого дела. Непорядок...

TGB, Ну, в таком случае "длинный цикл" имеет смысл разве что для написания дурацких тестов, потому как обычный здравый смысл запрещает пользователю написать "содержательный фрагмент кода без использования C-функций и исполняющийся достаточно долго". Самый длинный цикл в моём скрипте - по тикерам, за которыми он следит, т.е. обычно несколько сотен. И только один раз он составил 20000 или чуть больше - это когда я хотел посмотреть на бумаги Финама. Но даже тогда всё работало и ничего не отвисало. Так что у меня даже фантазии не хватает, кому и зачем может понадобиться такой "длинный цикл". Разве что nikolz для написания подобных текстов.  

nikolz, Так что же такое "длинный цикл"? Гугл тоже не знает: по запросу выдаёт ссылки на менструальый цикл. Но что бы это ни было, лапуль, он спрашивал: "Где вы увидели МОЙ код с длинным циклом?", а Вы привели его цитату про блокировку потоковв QUIK выполнением длинного цикла ПОЛЬЗОВАТЕЛЬСКОЙ ПРОГРАММЫ.

nikolz, Опять Фантомас разбушевался?

Лапуль, почти полвека программирую, но что такое "длинный цикл" - первый раз слышу! А знать бы надо, раз уж это дело "верх непрофессионализма в программировании и дилетантства в обработке данных". Не соблаговолите ли рассказать про этот "верх"?

Лапуль, ДА НАСРАТЬ, что "поток колбеков и main имеют общий глобальный стек"! Если они его, конечно, имеют - какая разница?. Лично я завёл в самом скрипте ТРИ "глобальных стека", и все эти "проблемы зависания квика" просто перестали существовать.

Лапуль, а вот для меня понятие "чистый" луа очень даже осмысленное. Это означает, что весь код скрипта написан ТОЛЬКО на Lua, без всяких библиотек, сишных конструкций и прочего дерьма, причём работает он на ЛЮБОЙ версии Lua, то есть не загажен операторами, зависящими от версии языка. Например, мой скрипт именно такой, на чистом Lua - чище не бывает!

nikolz, И чего? Это кому-то мешает? sec_code, seccode, SecCode, sEcCoDe - какая разница, если всё это работает? Синонимы имён атрибутов испокон веку применялись - как минимум, в базах данных. Вот было loadstring - "внесли творческий вклад", заменили на load. Ну, заменили, и заменили. А на кой было loadstring убирать? А здесь НЕ убрали, и правильно сделали: какая-никакая совместимость снизу.

nikolz, Лапуль, из нас двоих писать чушь давным-давно подвизались именно Вы.

Открою Вам ещё одну страшную тайну: у меня НИ РАЗУ В ЖИЗНИ не выставлялись заявки по рынку! Все 100% именно лимит. Тем не менее, они ПОЧТИ ВСЕГДА "не выставляются, а исполняются и тем самым двигают рынок и расширяют спред". Сами догадаетесь или разжевать?

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

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

Вот именно, лапуль: "Первой конечно придет заявка HFT робота", который после этих нововведений уже будет иметь точную информацию, что ему нужно делать.  

Что-то вы не то говорите, господа. С чего вы взяли, что "дела c ликвидностью совсем плохи"? Во-первых, изменения касаются именно срочного рынка, где продают воздух, продают ожидания - а какие могут быть здесь проблемы с ликвидностью? Тем более, что объём срочного рынка, насколько я знаю, в разы превосходит фондовый, а там "почему-то" никаких "проблем с ликвидностью" не просматривается. Во-вторых, "комиссия будет взиматься только с клиентов, которые заключают сделки по уже выставленным заявкам". Если два трейдера одновременно подали заявки по одной цене - один на покупку, другой на продажу, то та, которая первой прилетит на биржу, и будет считаться "выставленной", а опоздавший получит комиссию за эту сделку: кто первый встал, того и тапки. Таким образом, при любой сделке комиссию платит одна из сторон (в теории - на практике в вышеприведённом примере определить того, кто. освобождается от комиссии практически невозможно). Иными словами, поощряют тех, кто предоставляет информацию о своих намерениях: заявка должна полежать какое-то время в стакане. Это даст дополнительные преимущества тем, кто сидит ближе к рынку и может, воспользовавшись этой информацией, перехватить заявку и через миллисекунду перепродать её участнику, который уже обозначил свою желаемую цену и который за это был милостиво освобождён от уплаты комиссии. Кроме того, он платит за это дело временем ожидания совершения сделки, которое, очевидно, растёт, а также снижением вероятности её исполнения, будь все его заявки хоть 100500 раз лимитированные: ему платят ЗА ИНФОРМАЦИЮ! Точнее, даже не платят, а просто не обдирают как тех, кто этой информации не даёт. Далее: "Скидка на скальперские сделки больше не применяется". Вроде бы, разумно - во всяком случае, меня этот HFT-суходроч всегда раздражал. Но, простите, требование, чтобы заявка непременно полежала в стакане, стимулирует как раз то, чтобы спред был вычерпан досуха! А это, в свою очередь, стимулирует как раз скальпинг, обеспечивает его необходимым материалом, в то время как сам скальпинг, наоборот, должен бы расширять спредовые границы. Таким образом, скальпинг вроде как стимулируется, но скидка за него не даётся - полное ощущение, что эти меры направлены как раз на поощрение скальпинга, но только "для особ, приближённых к императору".  

Kolossi, Аналогично. Лихорадочно начал гуглить, что за зверь "теория японских свечей",    

Serge, Да плевать мне, откуда взялось "боди"! Для полноценного программирования на Lua это нафиг не нужно.

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

Serge, При чём тут вооще "из какой области вызывается выражение"? Эта дура его НЕ ВИДИТ! Глобальные переменные у меня действительно объявлены до main, но, полагаю, и это не имеет значения (в смысле, НЕ ДОЛЖНО иметь значения). Я не помню, есть ли у меня неинициализированные глобальные переменные (скорее всего, нет), но, полаю, и это не должно иметь никакого значения - здесь переменные глобальные по умолчанию (что есть ещё один идиотизм языка). Я же говорил не о переменных, а о функциях, которые по определению "объявлены за пределами main".

Чо ещё за "body" здесь нарисовалось?   ЧАВО???!!! Что, ФУНКЦИИ "объявляются внутри main"?! Воистину, программисты вымерли!

nikolz, Лапуль, мне НАСРАТЬ на всю эту клиническую мутоту с потоками, которая вдарила в головожопы создателей этого, с позволения сказать, "языка". Я в своё время потратил две или три недели, чтобы гарантированно перенести все операции именно в поток main (три стека для этого пришлось завести!), и с тех пор горя не знаю. Так В ГРОБУ я видел такую "матчасть" - учите сами!  

Nikolay, Как это "в момент вызова foo она еще не определена"? У меня в скрипте первой функцией стоит main, а за ней ещё десятка два, обычно по алфавиту. Всегда все всё прекрасно видят. Да и Квик перед запуском делает что-то вроде компиляции кода.

Nikolay, Всё ещё хуже: что последовательность их прихода не гарантирована - это полбеды, это, так сказать, пройденный этап. Вот фрагмент одного моего исследования подобных ситуаций:

Трижды прерывания о сделках приходили уже после снятия соответствующих заявок:
17:46:52 заявка подана, 17:50:19 снята, 17:52:41 пришла колода прерываний (почти 6 минут)
17:56:16 заявка подана, 17:59:47 снята, 18:02:57 пришла колода прерываний (более 6 минут)
18:12:32 заявка подана, 18:15:57 снята, 18:30:01 пришла колода прерываний (17.5 минут!!!)

Ещё более интересно, что прерывания по двум заявкам пришли БЕЗ уведомления об их снятии:
15:39:22 заявка подана, 15:51:59 пришла колода прерываний (12 минут).
15:45:27 заявка подана, 15:46:38 пришла колода прерываний (1 минута 11 секунд!!!)

Здесь важно вот что: я подаю транзакцию на снятие заявки только в том случае, если она активна. В первых трёх случаях снимаемая заявка была ещё не исполнена (или исполнена, но Квик об этом не знал). В четвёртом случае она была НЕ активна, и Квик об этом ЗНАЛ! Знал, паскуда, и 9 минут молчал! Возможен и другой вариант: скрипт не нашёл этой заявки в таблице заявок, но в этом случае Квик не успел обновить таблицу за ТРИ минуты после получения команды от скрипта, что совсем уж ПЦ! Наконец, последний вариант: заявку-то он нашёл (ID транзакций совпали), но стандартная функция получения данных из таблицы getItem глюкнула и предоставила неверные данные либо глюкнуло ещё что-то, и данные в таблице изначально были неверными.

В последнем же случае вообще кошмар: заявка ещё не должна быть снята (я снимаю их через 3 минуты активности, а прошло чуть больше минуты). Однако во всех пяти случаях перед диагностикой "ошибка при сделке" шла другая: "не нашли - левая сделка". То есть элемент в стеке сделок не найден. Но по логу чётко видно, что совпадает и код тикера, и ID транзакции, и цена, и количество. Стало быть, нет ни одной причины его не найти - разве что какая-то сволочь (в смысле, я, любимый) удалила паспорт ДО истечения трёх минут. Остаются классические два вопроса: а) кто виноват и б) что делать.

nikolz, Лапуль, по пунктам:

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

2. Если "всего было выставлено и снято 200 тысяч заявок по 200 инструментам", то это суходроч с заявками без сделок, что означает либо что Вас вообще не интересуют сделки либо у Вас нет хоть сколько-нибудь нормального алгоритма выставления заявок.

3. Фраза "Необходимо обрабатывать состояние не только заявки но и транзакции" глупа. Лично я не обрабатываю ни то, ни другое - это называется "искать на свою задницу приключений" - хотя бы потому, что системный софт в Квике просто ужасен, и крайне желательно сократить общение с ним до минимально необходимого количества (лично у меня это прерывание OnTrade и обращение к таблице orders, что я считаю самым оптимальным вариантом из всех возможных).

4. Перебирать таблицу заявок на 200 тысяч заявок - идиотизм, и не потому, что "упаритесь это делать", а потому, что это ИДИОТИЗМ!

5. Где Вы выкопали "таблицу активных заявок"? Таблица "orders" - это таблица ВСЕХ заявок - активных, неактивных, исполненных, частично исполненных или снятых.

6. Любой нормальный человек ведёт учёт своих активных заявок по каждому инструменту - это нетрудно: количество таких заявок лично у меня очень редко превышает 1-2 десятка даже при тысячах обслуживаемых тикеров. Что же касается ИНДЕКСОВ активных заявок - а откуда Вы их, собссно, знаете? ID заявки формируется не Вами, в отличие от ID транзакции (что есть ещё один идиотизм: обеспечение уникальности идентификатора транзакции возлагается на юзера, а в 99 случаях из 100 это малоквалифицированные программисты вроде Вас).

7. Идиотизмом также являются решения как повеситься на все возможные прерывания, так и беготня по всем таблицам по которым можно бегать: нормальные люди снимают заявки ПО ТАЙМЕРУ! Это даёт возможность плевать сто раз на то, будет ли заявка принята или отвергнута кем бы то ни было: если она не привела к сделке, значит, она неудачная (по ЛЮБЫМ причинам). И с какого бодуна "из таблицы активных заявок выбирается та, которую надо снять"? Вы что, сами не знаете заявки, которую хотите снять? А на кой тогда Вы вообще ведёте свой учёт своих активных заявок? Ах, Вы айдишки её не знаете? Да, бывает такое - У МЕНЯ бывает, поскольку я вешаюсь только на OnTrade, и если по заявке не было ни одной сделки, я этого не знаю и знать не могу. Именно в таких случаях (очень редких случаях, поскольку более 90% моих заявок исполняются в течение пары секунд) я и лезу в таблицу "orders", чтобы узнать ID заявки, которую я хочу снять, если она до сих пор активна - как правило, это менее 10 раз в сутки. При этом выполнение команды на снятие я вообще никак не контролирую - смысла нет: вдруг она исполнилась именно в тот момент, когда я подал транзакцию на снятие или команда эта по каким-либо причинам не прошла. А потому скрипт сразу же после отправки команды считает, что заявка снята (в подавляющем большинстве случаев это так и есть), но паспорт заявки из стека не удаляет до конца сессии - если вдруг эта "снятая" заявка сработает, мы будем знать, что это именно НАША заявка сработала. Если же заявка исполнена полностью (что опять-таки происходит в подавляющем большинстве случаев), то нам вообще плевать, что там кто по этому поводу думает - мы тут же можем удалять и паспорт из стека - ну, придут дубли этой же сделки - игнорируем: заявка больше НЕ НАША.

8. Интернет - такая штука, что никто В ПРИНЦИПЕ не может гарантировать, что "это сообщение приходит раньше чем сообщение о снятии в таблицу заявок", и закладываться на это в алгоритме - очередной идиотизм.

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

Станислав, У меня давно стоит снятие несработавших заявок через 3 минуты, при этом я ищу заявку в таблице "orders" и, если она всё ещё активна, подаю команду KILL_ORDER. Исполнение команды не контролирую никак - считаю, что как-нибудь будет снята. Так вот: мой личный "рекорд", когда заявка сработала, будучи либо уже неактивной на момент снятия либо после получения команды на снятие, составляет СЕМНАДЦАТЬ С ПОЛОВИНОЙ МИНУТ!!!

БорисД, Под "дворником" здесь понимается сборщик мусора. А на всех маркетмейкеров и кукловодов мне плевать - пусть вклиниваются куда хотят - они меня вообще не интересуют и ничего мне сделать не могут.  

TGB, Важная доработка!   У меня единственный на весь скрипт обработчик OnTrade и всё, что он делает - сбрасывает в стек полученные в прерывании trans_id, order_num, trade_num, sec_code, flags, qty и price для последующей обработки в потоке main. Честно говоря, мне плевать даже на то, вклинится туда этот "дворник" или нет. А вот подача кучи прерываний на одно событие когда-нибудь убрана будет? Именно по этой причине у меня только один обработчик - я когда-то не прочь был и на OnOrder повеситься.

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

Кстати, свой первый код (для работы по историческим данным) я написал именно на C - пощупал его, потестировал, а потом уже перенёс на Lua.

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

Лапуль, открою Вам страшную тайну: любой интерпретируемый язык сначала интерпретируется, а уж потом исполняется. И носом торкал: VM - это ТОЖЕ интерпретатор! Года два уж прошло, лапуль - пора бы и усвоить!

Чистый СИ, лапуль, это тоже всего лишь язык (его также называют машинно-независимым ассемблером), но компилируемый. Компилятор - это такой интерпретатор, который только интерпретирует код, но не выполняет его, а вместо этого записывает его на другом языке. Шурупен зи? В частности, компилятор с Си для Интеловского процессора даст радикально другой код нежели, скажем, для процессора PDP.

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

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

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

Учите матчасть, лапуль, который уж раз говорю.  

Старые песни о главном. Чуть ли не с самых первых своих сообщений я говорил: несмотря на то, что Lua есть препоганейший язык, а С мой наилюбимейший язык на протяжении десятилеий, писать нужно только на чистом Lua. А уж привлекать сюда ещё какое-нибудь говно вроде Python и вообще есть мазохизм в чистом виде. И что задача организации торговли настолько тривиальна в техническом плане, что работать должен один-единственный скрипт написанный на одном-единственном языке Lua и, по возможности, работающий в одном-единственном потоке main. Блин, она ещё и платная?! Как говорил незабвенный Пётр Павлович Ершов: "Пусть полюбится кому, я и даром не возьму".    

Nikolay, Мне - не нравится. Считаю сам.  

Nikolay, Не совсем так: торгую как раз ТОЛЬКО я - это я "купил 5 штук по цене X, потом еще 3 по цене Y, потом продал 2 по цене Z". Я их купил, это моя собственность, и только я могу знать, какие именно из них я продаю (хочу ли я это знать - это другой вопрос). Но ни брокер, ни кто-либо ещё этого знать в принципе не могут, и потому вынуждены считать по FIFO.

Переписать скрипт на Lua - всё остальное в морг.

nikolz, Не просто "всем известна  рекомендация не делать ничего в колбеках, а переносить все в main", а известна она, как минимум, полвека. И не надо проводить никаких экспериментов - абсолютно очевидно, что прерывания происходят в случайные, непредсказуемые моменты времени, а потому следует оттуда уматывать как можно быстрее - хотя бы для того, чтобы одно прерывание не столкнулось с другим. Я не знаю, что такое "колбек AllTrade" - может, OnAllTrade? Так он нафиг не нужен. А если OnTrade - так это единственный коллбек, который я использую. И вот как раз для него я и завёл третий стек, и как раз с целью разгрузить обработчик и вынести всё в main. Потому как обработка там не чета Вашему убогому
"эксперименту" - там требуется: а) проверить, не дубль ли это (прерывания от Квика приходят целой колодой, причём вразнобой), а это уже сама по себе операция нетривиальная и довольно дорогая - прерывания могут приходить вперемешку по разным тикерам, разным заявкам одного тикера, разным сделкам по одной заявке. И всё это "в трёх экземплярах". А ещё неплохо бы определить, наша это заявка или левая (может, юзер руками что-то купил/продал, может, другой скрипт). А потом не хило бы узнать, что это такое: покупка или продажа, открывающая сделка или закрывающая, лонговая или шортовая, на рубли или на доллары, прибыльная или убыточная (для закрывающих), какая взята комиссия брокера и биржи. А затем неплохо бы откорректировать данные портфеля и кошелька, разобраться с зарезервированной наличностью (если деньги резервировались) и, возможно, что-то сообщить пользователю. Это отнюдь не код Вашего сраного "эксперимента" - это НАМНОГО более трудоёмкие операции!

s_mike@rambler.ru,Если доработка софта не несёт никакой функциональности и не исправляет имеющиеся ошибки, полезнее промолчать. У вас с этим проблемы. А я впервые слышу об этом именно потому, что для торговли вся эта таблица нафиг не нужна - тем более, её поле class_codes.

s_mike@rambler.ru, А зачем ещё и этим забивать голову разработчикам "лучшего в мире ПО"? Я вообще первый раз слышу про существование таблицы trade_accounts, и мне АБСОЛЮТНО по барабану, "что некоторых классов из class_codes нет в таблице classes". НА КОЙ они нужны? Мой скрипт заглатывает при старте из входного файла перечень тикеров, за которыми ему велено следить, и там у каждого указан и код тикера, и код класса, и всё остальное, что скрипту надобно знать. Да пусть эта таблица тыщу лет не работает - упаси, Господи, от новых версий!

БорисД, Борь, у меня сегодня ночью всё легло в единую схему, абсолютно всё! И фондовый рынок, и срочный, и свечная торговля, и спредовая. Пока меня лучше не кантовать денёк-другой, я тебе подробно отпишу потом по мылу. Коротко по твоему сообщению:

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

2. Умный робот на Луа и в Квике возможен. Не этот долбаный ИИ, конечно, а просто очень качественный, который заткнёт за пояс любого трейдера, торгующего руками.

3. Нет, "имеем" не значит "предполагаем", это значит "удалось выяснить из прочитанных статей".

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

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

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

7. Да, "доят лохов, в основном, не на этом", но и на этом тоже. А "психология" скрипт мало волнует: нервы у него крепкие, да и внимательность на высоте.

8. Да, с твоими аппетитами стакан нужен, как и собственный сервер на бирже, но в Квике это бесполезно пытаться использовать. Забыли, как страшный сон! Как говорил незабвенный Владимир Ильич: "Мы пойдём другим путём".  

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

Прям заинтересовался: кому и на кой может понадобиться стакан? Полистал пяток первых попавшихся статеек на эту тему от тех, кто эту хрень рекламирует. В смысле, считает хоть как-то полезной. Имеем:

1. Обнаружение айсберг-заявок. Обсуждалось когда-то здесь. Выяснилось, что они нафиг не нужны, а обнаружить их в стакане можно лишь тогда, когда их подаёт очень тупой инвестор. Или, наоборот, очень умный, который хочет, чтобы его заявки были обнаружены. А спрятать айсберг от доморощенных аналитиков при желании проще простого.

2. Ух ты! "Сейчас биржевые стаканы считаются довольно устаревшей моделью анализа рынка и поэтому все меньше трейдеров ими пользуются". Дык я про то и говорю! Лично я этим говном не пользовался никогда. Разве что при ручной торговле, ещё до появления своего первого скрипта. И не для анализа, разумеется, а для совершения сделок. Ну да, тут и говорят про то, что всякие кукловоды доят лохов на фиктивных заявках и других "стаканных" разводках.

3. Собссно, больше в этих статьях ничего и не написано - так, ликбез, что такое стакан, бид, аск и прочая лабуда. Ха-ха-ха! "Вникать в анализ биржевого стакана полезно скальперам. Трейдерам на более длинных дистанциях следует ориентироваться на уровни поддержки/сопротивления и различные индикаторы". Детский сад!

4. О! "Кому нужен биржевой стакан цен". Вот я как раз и пытаюсь выяснить. Так кому же? Не, ну болтовня на тему "таблица предоставляет возможность отслеживать текущие сделки по ценной бумаге, оценивать настроения рынка и сформировать собственную линию поведения" меня не интересуют - кому и на кой? Увы, больше ничего, кроме блеяния на тему "внимание следует обращать на крупные лоты, а если у вас не крупные инвестиции, то достаточно аск и бид" или "необходимо применять комплексный подход". В общем, говно этот стакан. Как и "уровни поддержки/сопротивления и различные индикаторы". Как и многопоточность.

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

А так согласен: "Хоть тысячу отдельных потоков сделай, они все встанут в очередь при обращении к хранилищу".

БорисД, Согласен: 100 тысяч сделок в сутки - это всё равно никакой не HFT, это примерно две сделки в секунду. А если в портфеле сотня тикеров, то в среднем у них и вообще получается одна сделка в три минуты. А если 1000 тикеров... Но для Квика это почти предельная скорость.

nikolz, Лапуль, да хрен бы с ним, со сборщиком! На кой Ваш сраный "сервер в датацентре", если торгуете через брокера? А у брокера сервер где? Прямая торговля на бирже? А за каким тогда нужен этот убогий Квик с не менее убогим Луа? И говорил уже: Ваш суходроч с ЗАЯВКАМИ не говорит вообще ни о чём. Вот когда Вы "примерно за 4 часа совершите 150 тысяч СДЕЛОК", тогда можете о чём-то говорить. Хотя слабо верится, что у Вас денег хватит хотя бы на одну минуту такой работы.

nikolz, Лапуль, подсказываю:
1. Слово "подскажите" в данном случае нужно писать через "е".
2. Потоки - понятие алгоритмическое, они могут быть организованы в любом количестве, но, как правило, в этом нет никакой необходимости: они являются главным источником тормозов и глюков. Идиотизм нынешней реализации QUIK как раз в том, что юзерам (по определению малоквалифицированным) подсунули ДВА потока, да ещё и подали этот маразм как крутое решение. То же самое со стеками: в моих программах не раз встречалось несколько стеков (максимально 5 или 6 - уже не помню), но это только для ОЧЕНЬ специфических задач! Для такой же примитивной задачи, как организация торговли, у меня изначально не было НИ ОДНОГО стека. А сейчас их целых ТРИ, и все до единого созданы лишь с целью борьбы с последствиями работы банды полуграмотных придурков, сварганивших ТАКОЙ программный интерфейс. Лапуль, дружеский совет: перестаньте заниматься хернёй, забудьте, как страшный сон всякие вумные словечки, вроде "вектора", "потоки", "пакеты", "мьютексы" и прочую белиберду - пишите в ОДНОМ потоке. И будет Вам ЩАСТЬЕ! Вот слова "синхронизация", к сожалению, забыть не получается, поскольку у этих дебилов всё-таки ДВА потока. Впрочем, я давно понял, что Ваша задача не написать нормальный скрипт, а изображать из себя крутого программера. Плохо получается, лапуль. Позорно плохо!

nikolz, Один поток main для всех инструментов - это единственное устойчиво работающее решение при всех глюках системного софта.

Мне плевать на "конкретное затраченное время на обработку изменений всех инструментов в потоке main". Я уже говорил, что раз в секунду опрашиваю все курсы из ТТТ, за которыми следит скрипт. Раньше опрашивал раз в полсекунды, но особой необходимости в этом нет - точность измерений почти одинаковая. Отчего же меня не устраивает такое решение? Тысячу-другую тикеров скрипт держит без проблем - чего ещё желать? А уж про масштабирование и заикаться нечего: всё прекрасно масштабируется и числу тикеров, и по величине кошелька, и по частоте сделок. По чему ещё требуется масштабировать?

Ах, Вы опять ловлей этих дурацких микросекунд занялись. Ну, флаг в руки. Когда коту делать нечего...

Лапуль, HFT предполагает высокую частоту СДЕЛОК, а не суходроч с заявками. А сделкам насрать на все Ваши микросекунды - они будут тогда, и только тогда, когда найдётся покупатель на продаваемую мной сделку и продавец на покупаемую.

Да, лапуль - со мной вообще говорить не серьёзно. Мой алгоритм работает и зарабатывает, а Ваш суходроч только на тесты мудацкие годится. Это в лучшем случае.

ЗА КАКИМ ХЕРОМ, лапуль, Вам "делать скрипты на луа многопоточные"? Что, зарабатывающие делать не получается, Данила-мастер?

О! Самообучающийся робот - это круто! Раз у разработчика мозгофф не хватает, так вдруг самообучающийся робот сам справится? Браво, лапуль! Бурные продолжительные аплодисменты, переходящие в овацию!

Мне, честно говоря, настать, чистый там луа или QLUA и даже чем они отличаются. Оба языка есть полное говно, а в сортах говна разбираться я не намерен.

Лапуль, сколько можно повторять? У меня НЕТ никаких тормозов, мой скрипт спокойно работает с ТЫСЯЧАМИ тикеров, чего, как я полагаю, Ваше "микросекундное" говно делать не способно. Я прав?

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

TGB, Специальный сервер на бирже с прямыми каналами доступа к торгам тоже не поможет - Квик, батенька! Да ещё и Луа. А, ну да - ещё не дочитал до конца.

Предлагаю определение: HFT роботы не "манна небесная", а индикатор отсутствия у разработчика хоть одного мало-мальски пригодного алгоритма торговли.  

nikolz, Ни секунды не было сомнений, что "робот с любым числом алгоритмов и любым числом инструментов должен работать  в одном скрипте QUIK"

На весь скрипт имеется один-единственный колбек, который, естественно, существует в одном экземпляре.

Любой алгоритм для работы робота пишется в виде скрипта на чистом луа, без QLUA и выполняется в потоке main для всех инструментов.

Параметры по инструменту или портфелю хранятся в одной глобальной переменной (таблице Lua) и никуда не передаются.

И никаких индикаторов!

Тестировал  данную реализацию на разном количестве инструментов - обычно до двух тысяч (пробовал и на 20000, но притормаживает).

Ну очень нравится как оно работает в любой из версии Lua и QUIK.

Всё это работает вообще без каких-либо библиотек.

Очень быстро у меня исчезли любые пожелания по допиливанию QUIK. Я их просто боюсь - не все ещё глупости сделаны.

А насчёт HFT на QUIK согласен: это диагноз.  

nikolz, Стек-то LIFO, если брать только очерёдность обслуживания, но это не обязательно. Чистый стек, который однозначно LIFO у меня только стек прерываний. А стек сделок уже не стек в классическом понимании - там выбирается та сделка, которая сработала - и элемент с этой сделкой может располагаться где угодно. А на его место закидывается действительно последний на данный момент, чтобы дырок в массиве не было, а размер стека тоже уменьшается на единицу. Абсолютно та же техника и в стеке заявок, но там элементы вообще выбираются чуть ли не в порядке очереди. Но не совсем - некоторые элементы могут выбираться и вне очереди. А от стека во всех них то, что меняется всегда именно последний элемент - либо выбрасывается из стека, либо переносится в дырку. И что значит "максимальный размер"? ТЕКУЩИЙ размер! И он в большинстве случаев вообще нигде не хранится (для статических массивов), либо хранится в отдельной структуре данных, а нулевой элемент может использоваться и как обычный элемент массива, и для хранения метаданных о самом массиве. Например, нулевой элемент массива тикеров представляет собой сложное разветвлённое дерево на несколько десятков полей. Всё определяется удобством доступа к данным в каждом конкретном случае.

Как мне много лет назад ответил один программист, когда я ему тоже заявил, что стек это просто LIFO: "Просто LIFO - это магазин к АКМ". И он был прав!    

Nikolay, Это если их инициализировать прямо в коде. У меня большинство массивов начинаются с нуля, а за дырками (в тех массивах, где они возможны) и размерами массивов слежу сам. Например, в стеках (заявок, сделок, прерываний) длина массива (она же ID последнего элемента) хранится как раз в его нулевом элементе. Очень удобно и очень надёжно, и плевать, что там "оператор #" по этому поводу думает - им я вообще не пользуюсь. Не говоря уже про "переопределенные метаметоды".