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

В этом нет ничего странного. Количественный анализ ленты сделок - это обычная практика, особенно вместе с анализом стакана 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 записей, больше не выдается.

В мире финансов принято работать с целыми числами. Именно по причине ошибок арифметики с плавающей точкой. Для примера https://ec.europa.eu/economy_finance/publications/pages/publication1224_en.pdf
Чаще всего это делают приводя число к целому виду (числу пунктов), так называемый decimal type.

Для примера, цена 145.53 при шаге 0.1, должна быть приведена либо к 145.50 или к 145.60.
Значит в пунктах наша цена = 14553, шаг 10.

Тогда можно взять остаток от деления 14553%10 = 3. И если он меньше некого порога, например 5, то вычитаем его 14553 - 3 = 14550.
А если больше, для примера 14558%10 = 8, то прибавляем 14553 - 8 + 10 = 14560

Точная цена - это полученное число, обратно приведенное к разрядности. В данном примере это / 100.

Но это просто один из вариантов.

У брокеров существуют штрафы за число неэффективных транзакций (пустых), так и по числу транзакций. Но все это зависит от настроек брокера.
Также есть ограничение по числу транзакций в секунду.

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

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

Это Вам на форум nginx надо. Здесь совсем другой контекст.

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

Это сейчас серьезно? Почему же все эти годы не исправлялось. Сообщения были об этом очень-очень давно.

Для массивов так, конечно, быстрее.
pairs применяют для хеш таблиц, где простой итератор не применить.

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

Это такое поведение. Скорее баг, но ему уже лет 10. На графиках с очень большим число баров или на очень сложных "жадных" алгоритмах надо быть аккуратным.

Не думаю, что будут заметный эффект. Результат выполнения функции pairs есть функция next и t. Т.е. это просто синтаксический сахар, и это описано в книге по языку.
Минус один вызов, да.

Это почти всегда так для массивов. Но и в этом случае есть особенности https://www.lua.org/gems/sample.pdf
Читаем раздел про таблицы.

Для текущей задачи, когда постоянно происходить увеличение числа элементов массива, в конечном итоге будет произведен shrink таблицы.
As a consequence, if you traverse a table erasing all its fields (that
is, setting them all to nil), the table does not shrink. However, if you insert some
new elements, then eventually the table will have to resize. Usually this is not
a problem: if you keep erasing elements and inserting new ones (as is typical in
many programs), the table size remains stable. However, you should not expect
to recover memory by erasing the fields of a large table: It is better to free the
table itself.

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

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

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

Открываете пример MA.lua, например расчет SMA, и видите использование массива sum равного длине периода.

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

Пробежался и так не понял в чем проблема, и причем здесь очередь.
Озвучена проблема роста памяти при расчете индикаторов. Ок.
Но для расчета индикаторов нужен банальный массив. Тупо для каждого индекса бара от 1 храним какое-то значение.
Пришел новый бар - записали данные по его индексу. Все. Но такой вариант - это постоянное увеличение хранимых данных.
Что можно сделать? Банально очищать неиспользуемые данные, присваивая nil. Правда помня, что перестанет работать #. Но это решается очень просто.
Сложнее - можно сделать массив фиксированного размера и записывать данные по кольцу. Так сделали разработчики терминала в последней версии примеров расчета индикаторов.
Что это дает - объем занимаемой постоянен и контролируем.

Зачем здесь очереди, стеки и др. списки - не ясно.

VPM, я могу Вам предложить в качестве развлечения один проект https://github.com/kurapica/PLoop

Погрузитесь в крайнюю степень использования _ENV и все на чистом Lua.
Правда не ясно зачем, но, как говорится, красиво.

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

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

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

Поэтому я не использую глобальный контекст. Но его приходится использовать, если это методы и переменные из Qlua. Разработчики терминала все поместили в глобальный контекст. Поэтому и приходится к нему обращаться.
А для того чтобы это визуально различать и чтобы linter не выдавал ошибки, пишется _G, не более. Если бы интерфейс qlua был в библиотеке, например qlua, то было бы все лаконичней. Подключил библиотеку - получил методы и контекст терминала.

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

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

Добавьте в лог в разных подозрительных местах результат выполнения collectgarbage('count')
Будете видеть где происходит утечка памяти.

Да, DS - это таблица (класс) (в LUA всё таблицы), но там только методы и недокументированные переменные. Сами данные получаются через эти методы.

Что касается организации замыкания, то я никогда не понимал зачем в учебных примерах, предоставляемых ARQA, настройки и DS передаются в метод расчета на каждой итерации. Когда более логично их передать один раз при вызове конструктора экземпляра. Они будут запомнены через upvalue и никуда не денутся. Сам метод расчета требует только индекс бара (и что еще, если алгоритм требует), и не более.