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

И глядя на формат, выгруженный из кармана транзакций возникает странное ощущение.
Для примера, одна строка - это срочный рынок, другая фондовый.



Спрашивается, почему значения полей отличаются. В одном случае "Покупка", в другом "Купля". "Комментарий", "Примечание". "Торговый счет", "Код торгового счета"...
Где отдельное поле "Код клиента" для фондовой секции, тот что CLIENT_CODE.

И это только базовые поля для простого лимитного ордера.

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

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

По опыту, если есть окно скрипта, то задержка не меньше 50 мс. Если его нет, то можно и 10, даже 5 мс, ориентируясь на нагрузку ЦП.

Это просто вариация hack_trade. Если речь была про задержку потока main, то да она должна быть. Но секунда как-то много, хотя зависит от задачи, конечно.
Но т.к. в данном примере Robot - это сопрограмма, то не очень понятно зачем там задержка. Чтобы что?

Не очень понятно зачем задержки. При работе с сервером Вы не знаете когда придет ответ. У кого-то связь - GPRS, какой-то брокер не рассчитал нагрузку на сервера. В результате в тепличных условиях ответ транзакции приходит за 200 мс, а в плохих за 10 минут (реальная цифра). Поэтому эта 1 секунда не просто не нужна, а вредна.

Задача состоит из последовательных шагов:
1. Отправить транзакцию.
2. Обработать ответ транзакции.
3. Обработать появление ордера.
4. Обработать исполнение ордера.
5. Что-то еще, например, обработка изменения позиции

И все это вполне можно разбить на разные задачи. Т.е. надо отправить 100 транзакций - отправляем все разом. В колбеках (за неимением таблицы транзакций) проверяем ответы транзакций. Если ответ корректный, переходим к дальнейшей обработке - созданием последующих задач.


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


При этом на языке поддерживающим async/await - это можно было бы сделать проще. В Lua мы должны создавать задачи (не важно каким образом) и обрабатывать их квантами, не блокируя и не ожидая какие-то фиксированные секунды.

Также, для примера, можно организовать заказ данных через CreateDataSource. Это задача, которая не должна блокировать исполнение скрипта. Иногда надо заказать десятки таких потоков и если ждать по каждому из них по секунде, то через сколько же времени приедет последний. А если это заказ, проверка, то всегда можно перейти к следующей задаче, если на данный момент еще данных нет. И так проверять пока данные не приедут.

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

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

Да, но все это про переключение между сопрограммами. И если считать, что заканчивать свое выполнение они будут не в том же порядке, что создавались, то притянуть термин асинхронность можно.
Вам надо самому реализовать алгоритм переключения между задачами (thread scheduler). Надо его постоянно вызывать в бесконечном цикле. Т.е. ни о каком фоновом исполнении речи не идет.

Впрочем, думаю это уже не столь важно. Лишь бы не думали, что сопрограмма магическим образом сама выполнится пока я вызываю другую функцию. Это не про Lua.

Lua ни при чем, да. Я вступил в дискуссию только потому, что начали применять термины, уже давно устоявшиеся, в применении к языку. Что может привести к иллюзии, что язык это поддерживает.
Это также как применение функционального подхода к программированию на Lua. Сам язык, в чистом виде, не функциональный. Но если использовать определенные техники и конструкции, то вполне себе можно писать в функциональном стиле. Так и с асинхронностью.

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

Не надо приписывать свойства какому-то определению. Я дал ссылку на, по сути, автора.

Луа не нарушает принципы, а не обладает ими. То что есть сопрограммы, не делает язык Lua полноценно поддерживающим концепцию async/awit.
Вы можете сопрограмму остановить. Вот и все. Из этого не следует, что она асинхронна. В Lua вы все равно будете сами проверять состояние сопрограммы, вызвав ее. Т.е. вы должны написать код так, что будете перебирать все активные сопрограммы последовательно. А вот уходить из очереди перебора они будет не последовательно. Все.

В языках где поддерживается полноценная асинхронная модель, вы не занимаетесь постоянным "дерганьем" сопрограмм. Она САМА сообщит, вызвав колбек. И кардинальное отличие будет в том, что асинхронная функция не блокирует основной код, а в Lua так не выйдет, будете просто переключаться между сопрограммами, остальные заблокированы, т.е. не выполняются.

Вот еще одна статья с картинками https://learn.microsoft.com/ru-ru/dotnet/visual-basic/programming-guide/concepts/async/

Нет. Это не оно.

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

Вы же описываете немногопоточный concurrency. Как бы квази-парраллелизм. Хотя этот термин лучше не переводить. Впрочем, если считать, что задача 2 (поставленная позже) завершится раньше задачи 1, т.к. она просто быстрее выполняется, то да, наверно, чисто семантически, разбирая слово (a)sync это можно назвать асинхронностью. Хотя в данном случае просто мы переключались между задачами каждый квант и на вторую ушло меньше квантов, вот она раньше и выполнилась. Собственно в книге автора языка это описано в разделе 9.4. Невытесняющая многонитевость.

А сама концепция async/await была представлена в F# в 2007:

https://learn.microsoft.com/ru-ru/dotnet/fsharp/tutorials/async

Это просто один из подходов, чаще всего используемый в сетевом взаимодействии. Но все это можно сделать и на очереди, когда вы создаете объекты - задачи и просто их перебираете, проверяете пока очередь не опустеет. Это называется неблокирующее ожидание. Есть задача - готова, очищаем. Нет - переходим к следующей, ожидая эту. Т.к. терминал - это передача команд на сервер и ожидание ответа, то такой подход конечно необходимо применять.

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

Это не очень нормальное поведение. У меня бывает до 1000 транзакций. Каких-то особых "зависаний" не наблюдается. Впрочем, если Вы активно используете основной поток терминала, т.е. производите действия в колбеках, то вполне возможно, что так и будет. Я придерживаюсь мнения, что колбек это событие, которое необходимо обрабатывать в потоке main скрипта. Кроме как записать в очередь тип события в колбеке ничего не делается. Что касается железа, то я уже лет 15 не работал на машинах где было меньше 16-32 гб и 4 ядер, так что не знаю как терминал реагирует на слабое железо.

Также писал скрипт для проверки возможности записи слепка стакана в базу данных, а второй скрипт из базы уже читал и выводил в окно этот стакан. Тоже как-то все работало корректно, без особых притормаживаний.

Правда для светлой темы было такое - https://forum.quik.ru/messages/forum10/message46407/topic3777/#message46407. Ошибку, ниже в той ветке, обещали исправить. Давно не проверял починили ли, т.к. использую все тот же костыль для светлой темы.

Проверьте с новой нотацией <close>, что была введена в lua 5.4

local f <close> = assert(io.open(file, "ab"))

При это руками закрывать файл уже не надо.

Это тоже лучше делать в main. Число реакций на изменение стакана может быть десятки раз в секунду. Если не стоит задача сохранить состояние стакана в каждый момент времени, то лучше разбирать стакан по событиям, когда поток скрипта дойдет до этого.

Для примера, скрипт из сотни тысяч строк и его один цикл занимает до 1 секунды. Реагировать на изменения стакана, когда скрипт занят другим не имеет смысла, т.к. когда скрипт дойдет до разбора, его состояние изменится десятки раз. И все эти промежуточные состояния уже устарели. Но опять, если не стоит задача сохранить состояние стакана в каждый момент времени.

Сборщик мусора не вызывается на каждый тик. Поэтому какое-то время они там останутся.

Передать очень просто. Может прочитать примеры из руководства "Использование Lua в Рабочем месте QUIK". Хотя все очевидно - в колбеке какой-то переменной, записи в очереди, присваиваете какое событие произошло, а в main обрабатываете.

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

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

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

Проверьте написание функции:
OnCalcul ate

Почему есть пробел. Хотя, по идее, такой код не должен был скомпилироваться. Впрочем, может на графике просто нет индекса 5, дырявый график.

Да, это я пропустил взглядом эту строку. Советую просто вывести данные полученных параметров в лог, чтобы оценить что конкретно передается при вызове AddLabel.

В качестве второго параметра os.date принимает число (unix time), Вы же передаете таблицу.

Сегодня не подключиться к демо-серверу, пришет "Срок лицензии истек". Ранее фраза была другая, да и с 26.02 (когда доступ получался) прошло менее месяца.
Сделайте уже в форме запроса доступа флаг с автоматическим продлением доступа и, если угодно, контроля последней активности. Если последняя активность более месяца назад, то тогда и отключать доступ.


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

В этом нет ничего странного. Количественный анализ ленты сделок - это обычная практика, особенно вместе с анализом стакана DOM. Правда, конечно, это обычно не записывают в линейный файл, а используют базы данных.
Квик позволяет это делать без всяких скриптов, достаточно настроить выгрузку через ODBC из таблицы.
База данных позволит строить аккумуляцию, агреггацию, фильтрацию и т.д. Причем делать это быстро.

Не очень понятно зачем это делать через объединение строк.
У меня такие потоки для каждой новой записи просто пишутся в файл через
f:write(str..'\n')

Плюс организован счетчик добавленных строк. Когда их больше порога, скажем 100, сбрасываем на диск
f:flush()

И не очень понятно зачем это делать в колбеке OnAllTrade, загружая поток терминала. Да, конечно, так можно, но если скрипт запускается в середине торгового дня, да и просто перезапускается, то необходимо сканировать таблицу и записывать в файл пропущенные записи. Раз так, то проще сделать так и для новых записей.

Стандарт для lua это luacheck.

Также для vscode есть lua-language-server от sumneko. Оба показывают такие сообщения.

Для примера, такой код:

Код
local a = 5 local c = a + b

Получаем такие сообщения

luacheck: unused variable 'c'",
luacheck: accessing undefined variable 'b'"

Lua Diagnostics: Undefined global `b`."

Любой нормальный линтер поможет с этим.

Валюта - это деньги. Смотрите в таблицу money_limits

Да, Вы правы. Команда Play не поддерживает команды с именами файлов, которые нельзя привести к короткому имени, т.е. с пробелами. Посмотрел внимательно на MCI. Он действительно старый.

Но работает в команде Open.
Т.е. надо подавать две команды
OPEN "C:\\Windows\\Media\\Windows Hardware Fail.wav" ALIAS SND1
PLAY SND1

Для остановки команда
STOP SND1


Также такой подход будет означать, что после команды OPEN, в памяти сохранится ALIAS SND1. И повторно не надо уже открывать. Можно просто заново подать команду PLAY.

Да, но Вы это сделали некорректно. В Lua, если надо передать кавычки, можно использовать апострофы.

И при использовании w32 команда будет выглядеть так:

w32.mciSendString('PLAY "C:\Windows\Media\Windows Hardware Fail.wav"')

Вы же использовали кавычки не в том месте.

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

Зачем какие-то дополнительные знаки

PLAY "C:\\Windows\\Media\\Windows Hardware Fail.wav"

Все также как при работе с терминалом. Там тоже надо путь с пробелами обрамлять в кавычки. Весь путь, а не только часть.

Команда OPEN не нужна, если надо просто проиграть файл. ALIAS не нужен, его и нет в  документации для PLAY.

Чтобы брался путь с пробелами, необходимо путь обрамлять кавычками.

Я отправляю команду
mciSendString PLAY "filename"

Если отправить несколько команд, то будет играть сразу все отправленное.

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

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

PLAY

Все указано в документации https://learn.microsoft.com/en-us/windows/win32/multimedia/mci-command-strings
Можно даже проигрывать кусок из файла.

Если проигрывается WAV, то ничего не надо делать более. Если другой формат, то должна быть поддержка. MP3, кажется, тоже проигрывает без доп. усилий.

У меня оповещения на сработавший ордер иногда используются. Если бы это было с блокировкой через команду OPEN или с показом окна терминала, то при одновременном срабатывании нескольких ордеров будет печаль.

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

Я понимаю о чем Вы говорите, если Вы ссылаетесь на работу John F. Ehlers https://www.mesasoftware.com/papers/CORRELATION%20AS%20A%20CYCLE%20INDICATOR.pdf

Я такой индикатор писал https://github.com/nick-nh/qlua/blob/master/corrCycle.lua
Как и другие его циклические индикаторы CyberCycle, CenterOfGravity, InstantaneousTrend, MESA

Но, как обычно, в голом виде - все это академические работы.

Вы пишите о разложении некого сигнала на составляющие. Когда в конце 90-х физики решили обуздать рынок, тоже была популярна идея применить преобразование Фурье к временному ряду.  Точнее тогда появились технические возможности для этого. Соответственно появилось много работ по этой теме. Но достаточно быстро это ушло в область академических исследований. Опять же по причинам свойств временного ценового ряда. Это не значит, что все это бесполезно, но и точно не является какой-то идеальной системой.

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

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

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

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

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

Впрочем, мой ответ был на высказывание о ММ и его поведении, о предположениях о неком покупателе в РАСЧЕТНОМ контракте на очень маленькой прокси бирже и все это просто глядя на график, построенный по данным этой микроскопической биржи, без учета дынных о торгах на основной торговой площадке.

Просто к слову, торговля любым commoditie подразумевает анализ фундаментальных показателей, сезонности. Если задача - это элементарные краткосрочные спекуляции то да, можете торговать что угодно, выбирая любой метод принятия решений. Но даже в таком случае не удастся избежать элементарного понимая причин. Например, отрицательная цена на нефть в 2020 имела вполне себе логические причины. Надо было просто анализировать информацию о заключенных контрактах участников, не имеющих возможности произвести поставку, обработку физического товара, что приводит к закрытию позиций при экспирации. А если нет спроса, то об кого закрывать? ММ на товарном рынке не будет принимать такой контракт, т.к. что он будет делать с ним, где хранить. А прокси биржи, типа ММВБ, просто следуют за этим. При этом на ММВБ еще нет торговли ночью, что приводит к неприятным последствиям. Не учитывая все это и перенося позиции через ночь - это верх смелости. И жаловаться после всего этого на прокси, который, по сути, ни на что не влияет - это верх идиотизма.

В Lua нет именованных параметров. В строке задаете параметры. В функции может их назвать хоть p1, p2 ... Будет простой позиционный вызов.

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


Что касается ссылок, то всегда можно клонировать репозитарий локально.

А что вы хотите от простейшей сигмоидной функции. В тех же алгоритмах EM кластеризации, например Gaussian Mixture Model все намного точнее. Правда требуется подготовка данных и может долго производится подготовка модели.
После расчета уже все быстрее - по входным данным находится кластер, размеченный тем или иным образом.

Модуль как модуль, написан обычно.

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

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

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

Это не очень красиво брать тексты разработчиков и убирать Copyright информацию, даже если она под лицензией MIT.

Просто ссылку на исходник - это правильно.

Колбек нет. Но это не значит, что их нельзя читать. Вот, для примера https://github.com/nick-nh/qlua/blob/master/BidAskVol.lua

А зачем Вы отправляете еще одну транзакцию пока не дождались ответа от прошлой? Отправили, получили ответ, принимаете решение.

А в период аукциона ценовой коридор уже чем в основную сессию (и его не транслируют), поэтому отвергнутая транзакция вполне естественна. Можно отправить еще сколько угодно, но она будет отвергнута.

А если ответ корректный, как самой транзакции, так и колберка, то просто ждите пока ордера не появится в таблице ордеров.

Разве в документации сказано, что это поддерживается?

Я получал данные пакетами. Получаешь число записей, и в цикле запросы на очередной блок данных в 100 записей, больше не выдается.