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

В 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 и никуда не денутся. Сам метод расчета требует только индекс бара (и что еще, если алгоритм требует), и не более.

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

Я, кажется, уже писал Вам, что почти все индикаторы не требую хранения данных более чем период расчета. А у еще большего числа индикаторов таки вообще достаточно хранения данных на прошлой итерации, как, например, у EMA.
Поэтому, для начала, просто произведите оптимизацию расчетов. Большинство примеров из просторов глобальной помойки, совершенно не заботятся о том, что баров может быть под 60 тыс, и экземпляров расчета от 100 и более.

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

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

Думается, что это проблема выбора реляционной базы для хранения данных (правда мой опыт обработки всех сделок, всех акций за 2016 год на MsSQL не вызывал каких-то проблем, кроме объема, но это год). Хотя организовать порционную подачу данных вполне можно. Заказали - начинают поступать данные. Если же сделано, что сначала все данные подготавливаются, кешируются и только потом выдаются всем объемом, то, наверно, это и приводит к таким задержкам. Плюс, видимо, у таких данных очень низкий приоритет, так что не во все пакеты попадают.  

Корутины имеют накладные расходы. Внимательно посмотрите на код решения, что Вы используете, и Вы увидите там точно такой же цикл опрашивающий корутины.
Что касается быстрых и медленных задач, то они реализуются одинаково. У них разное время выполнения, поэтому одна завершится быстро, другая будет долго выполняться, а какая-то будет вообще всегда работать. Техническая же реализация - это в одном случае Вы их заворачиваете в корутину через wrap, а в другом реализуете более сложный объект, точно так же хранящий свое состояние. А уже какая будет скорость работы самого этого объекта, корутины - сами и определяете. Я не вижу никакого смысла добавлять какие-то задержки в исполнение, что в одном случае, что в другом. Также как и нет никакого смысла перебирать объекты, корутины с задержкой. Единственная задержка добавляется в бесконечный цикл в main, и то, потому что иначе Квик зависнет.
Вот и вся разница. Используйте, никто не мешает. Но не надо говорить о многопоточности, многозадачности и т.д.

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

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

Подниму тему. Необходимо получить данные по календарным спредам. Набор параметров для них хоть и близок, но другой. Для примера, две даты эксприации.
Но вот незадача - у меня нет Excel и нет желания его устанавливать. Тем более, что он платный. Украсть просьба не предлагать. А получить иначе набор параметров Вы не предлагаете. Собственно вопрос:  как быть?
Я воспользуюсь, конечно, библиотеками, соберу DDE сервер. Но это не решение вопроса. Неужели так сложно обновлять информацию в документации? У Вас теперь релизы терминала выходят чаще, чем этот набор параметров изменяется.
И я банально не понимаю причины, почему это не делается.

Раз уже здесь писали об ошибках потоков...
Поймал ошибку, видимо ошибка потоков. Версия 11.0.0.92, lua 5.4

Обрыв связи, восстановление. Заново приходят все коллбеки с начала сессии до момента разрыва связи (здесь сразу вопрос - как бы это отключить?). В этот момент алгоритм находиться в цикле, перебирая некую таблицу.
По логу вижу, что есть сообщение колбека, есть сообщения из цикла. И в какой-то момент цикл разрушается - получает данные из другой области памяти. Итеративная переменная 10, а получены данные по индексу 20, например.
Или еще хуже - получены данные из совсем другой таблицы.

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

Это одновременно и простой и сложный вопрос. Таблицы в луа это ссылочный объект.
Т.е. запись my_array ={} создает новый объект - объявляет и инициализирует. В переменной будет новая ссылка, а старая безвозвратно утеряна, и очищена сборщиком мусора, если на нее не было больше ссылок.

Поэтому, если вопрос: как очистить существующий объект, то ответ - пройтись циклом и присвоить nil для ключей, индексов.А запись my_array ={} "как бы" очищает, да. Но при этом будет новая ссылка и если есть блоки кода, хранящие ссылку на my_array, то они не увидят новую, без повторного присвоения.

Проверьте все задаваемые параметры в документации или здесь https://luaq.ru/AddLabel.html
Например, нет такого параметра datetime. Также имена параметров регистрозависимые.

Сигнатура вызова NUMBER AddLabel(STRING chart_tag, TABLE label_params)

Первый параметр - это строка.

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

luac54.exe -s -o "*.luac" "*.lua"

Это убирает debug информацию.

Ну это дело такое - когда-то turbo pascal был чудесен. Или, для примера, Emacs, как среда  разработки, - великолепна. И до сих пор великолепна. Так что SciTE - это такой же новодел как VSCode.


А лучше добавить параметр -s. Правда если цель - писать скрипты для себя и только для себя, то зачем вообще компилировать. Квик это сам сделает перед запуском.

Кошек надо просто уметь готовить. VSCode - это просто среда. Все компилируется в терминале скриптами, самим же lua (или любым другим bash). Зачем для этого редактор - не ясно.
SciTE хорош, но, для примера, ZeroBrane Studio (по моему мнению) - лучше. Но она не умеет win1251.
Также советую проверить какую команду выдает SciTE для компиляции.  Скорее всего без -s, что оставит отладочную информацию и позволит декомпилировать код, если он компилировался в чистом виде.

SciTE не использую, так что не знаю. После VSCode - особого желания нет.

В lua 5.1 в исходном файле luaconf.h переменная LUAI_MAXUPVALUES = 60. Хотя можно увеличить до 250 и скомпилировать свою dll. Хотя Квик и не даст с ней работать. В lua 5.3 кажется увеличили это число.
Было бы конечно хорошо, если бы OnCalculate давал возможность работать с таблицей, а не конкретными значениями, или как-то иначе задавать значения линий. Иначе большое число линий вызывает проблемы.

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

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

Впрочем, дело вкуса, конечно.

Да, спасибо, как-то я про них не подумал.