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

DestroyTable нельзя вызывать в колбеке окна - это отражено в документации.
Вызывать OnStop руками, тем более в колбеке окна - тоже не надо.

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

Этот колбек самый опасный. Читать таблицу обезличенных сделок лучше пакетами. У Вас цикл работы скрипта. допустим, 100 млс. За этот период набежит много сделок. Дойдете до процедуры чтения и все пачкой прочитаете от прошлого индекса. И так читаете, опрашивая не изменился ли размер таблицы. Колблек же будет занимать основной поток терминала просто говоря, что прошла сделка.

Свою.

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

Поэтому можно, и нужно, формировать разные очереди. И даже в рамках одной очереди, лучше использовать две, разбивая их на четные и нечетные. И писать, читать поочередно.
Записал в четную, потом в нечетную, потом четную, нечетную.
Читать нечетная, потом четная и т.д.
Это частично может помочь избежать блокировок. Или просто случайным образом выбирать какую очередь использовать первую.

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

А зачем писать на диск, если mmap позволяет делать отражение в памяти.

Проверяйте, что не производятся расчеты в колбеках. Очень часто - это основная проблема. Более корректно - формировать очередь сообщений и разбирать в потоке main.

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

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

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

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

Если он не открыт, то надо вызвать Subscribe_Level_II_Quotes. Хотя можно проверить открыт есть ли поток данных через IsSubscribed_Level_II_Quotes, и если нет, тогда и заказать.
Делать это можно не в OnInit. Я бы даже сказал, что это точно не надо делать в OnInit.

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

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

Сам OnConnected не столь важен. Если вызван OnClenUp, то все данные таблиц пустые. А значит если логика скрипта проверяет данные из таблиц, то если не дождаться их загрузки, будут получены некорректные данные. А загрузка происходит совсем не мгновенно, иногда через минуты после прихода OnConnected.

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

Ну так для Si 100 шагов = 100 пунктов. Это не особо важно. 100 шагов - это мало. Если думаете, что РТС не может шагать по 100 шагов, то обязательно поймаете такое событие. Впрочем, на моей памяти такое было не раз с 2008 года.

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

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

Если алгоритм не учитывает наличие планок (да и просто сумму стакана), то это опасно. У нас планка - почти нормальная ситуация.
100 - контрактов - это не такой и большой объем. Отношение ГО к объему контракта не имеет никакого отношения к числу контрактов. Для кого-то 10 контрактов - это весь депозит, а кому-то 100 - всего 10%.

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

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

Учет комиссий не решается колбеками и данными из таблиц. Решается же он через обработку отчетов брокера. Комиссия биржи транслируется вместе с сделкой, поэтому её условно можно считать. Брокера же чаще всего транслирует "ерунду". И только в отчете за день будут точные цифры, т.к. они могу зависеть от оборота за день, типа инструмента и др, и в момент сделки точных банально нет. Так что гораздо проще в алгоритм вбить процент либо величину комиссии и учитывать её. А корректировать через разбор отчета брокера.

Ошибка т.к. обработка наивная:

pos = pos + sign*traded.qty

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

Вы забыли данные из других источников. Индикаторы - это настолько малая часть и почти бесполезная часть, что её проще реализовать отдельно. Основное же использование - это скрипты, зачастую без интерфейса, а просто выполняющие расчеты, сохраняющие результаты в файлы. Так банально проще, т.к. анализ данных проще делать в других системах, в том же Python, а не в индикаторах Квика.
Даже если это торгующий скрипт, то не ясно зачем ему график. График нужен человеку, для самоуспокоения, что всё правильно.

Еще важно, что иногда набор данных включает очень далекую историю, которую Квик просто не может предоставить. Например, данные баров выгружались за 5 лет. На основе этих данных строится свой источник данных с ТФ, например, равный 12 минут, 3 часа, 5 часов и т.д. Квик просто не дает такие данные. И уже этот источник поступает на вход алгоритма. Этот источник будет состоять из двух частей - кэшированные, верифицированные данные (что очень важно) и текущие данные реального времени.

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

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

Нельзя ответить на этот вопрос. Например, если поля broker_comission и broker_comission_currency не важны, то этот второй вызов бесполезен, а если важны, то уже нет. Хотя, если говорить о комиссиях брокера, то они их может не транслировать вовсе и можно ждать вечно.

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

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

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

Сразу возникает мысль, что не писали реального приложения через getCandlesByIndex.

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

DataSource - это методы, да. Но в этом-то и преимущество, т.к. этим можно управлять. Реализовать новый метод возвращающий такую же таблицу, что и getCandlesByIndex - это несколько строк кода.

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

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

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

Здесь вопрос в излишней сложности. Если не зависеть от графиков, то реализация становится простой - надо всего лишь указать список ТФ, инструмент итак есть, если скрипт ведет портфель (он же должен знать что в нем). График открывайте для контекста, никто не мешает. Но и не открывая его - все будет работать.

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

Легенда - это просто подпись под данными. То же, что видите на графике, если указано в настройках области графика  "Легенда". Т.е. это просто подпись. Если читаете Price, что это будет некое название инструмента. Если индикатор, то название индикатора. Решайте сами насколько это полезно.

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

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

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

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

Если хотите полный контроль над данными и полную синхронность, то просто рассчитывайте бары сами. Берете таблицу обезличенных сделок, читаете и строите бары любых ТФ. При этом, т.к. поток для расчетов один, то и разные бары будут получены в одно время. Т.е. это уже часть вашей архитектуры, а не зависимость от API Квика. Более того, такой способ позволит получать много дополнительных метрик, которые просто не доступны для баров Квика. Собственно очень многие сторонние системы, подключающиеся к Квику, так и работают - расчет по сделкам, дамп закрытых баров в кеш (файлы, базы данных). В итоге данные на истории всегда есть, получаете только новые бары. Также такой подход позволит оценивать систему в любой выбранной точке на истории без необходимости что-то заказывать в Квике. А если это сторонняя система, то и не открывая Квик.

Тогда объясните эти цифры.

 У баров есть единое пространство - это время. Индекс бара ничего не говорит, он не подходит для этих целей. Поэтому синхронизировать данные необходимо по шкале времени наименьшего ТФ или по наибольший общий делителю. При этом, т.к. бары могу быть построены по любым данным, то и ТФ может быть любым, например 30 секунд. В итоге, определяем квант времени, а далее по мере прихода данных происходит их обработка.
При этом если есть ТФ не кратные друг другу, то обработка может быть не синхронной, например бары 2 и 3 минуты. Будут моменты когда приходит бар 3 минуты, а бара 2 минуты нет и не будет в это время.

Ничего сверхъестественного. По большому счету это, то как глазами видят картину. Смотрим на графики и видим текущее состояние (или сдвинув графики на точку времени) и производятся действия в этой точке времени. Синхронизация не зависит от Квика и его особенностей. Представьте, что одновременно обрабатываете данные из Квика или API MOEX, API NYSE, API LME и API SEHK. Совершенно разные источники, разные соединения, разные задержки. И при этом работать же надо, а не говорить - это сложно, не будем.

Не любимый мной Python при использовании магических библиотек все сведет к единому классу, например, из Pandas. Все источники лягут в dataframe и работать с ними будет одинаково, и не важно как они получены.

Более важен вопрос - а надо ли это делать. Банально иногда нет причин. Выбрали один источник данных, с помощью которого получаете 90% данных, и реализовать работу с ним. А если надо будет получать данные иначе, ну добавите несколько методов, чтобы считать через него. У меня в скриптах внутри Квика все получается через CreateDataSource. Иногда через таблицу сделок для ТФ меньше минуты. Или чтение из csv файлов. Все это загоняется в простейшую таблицу у которой __index может ссылаться на ds, если он есть. И реализованы простейшие прокси методы повторяющие методы ds из CreateDataSource. Вот и есть универсальный контейнер. Если хотите использовать getCandlesByIndex - ничего не мешает, просто реализуйте методы O C H L Size Close. И получите единый интерфейс к данным. Но когда в скрипте нет задачи собирать данные, то проще и быстрее сделать напрямую. В конечном итоге - зачем выполнять лишний код.

Но, как написал выше - если это необходимо. Иногда все эти сказки из книг типа "Чистый код" - это теоретические изыскания, не имеющие никакого значения на практике, т.к. делают код очень медленным, объемным.

Ок. Но тогда просьба пояснить в каких единицах выражается поле доходность. Явно не проценты.

А причем здесь портфель? Это чисто техническая задача - получение данных баров для инструмента. Их можно получить из Квика, можно через API биржи, из других ресурсов, даже из своего кеша, чтобы каждый раз не делать запрос на все данные, ради одного нового бара.

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

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

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

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


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

Частично вопрос об ошибочном таге можно снять, если вызывать TABLE t, NUMBER n, STRING l  = getCandlesByIndex, т.к. она возвращает - l (подпись). Если ошибка в таге, то подпись будет пустой.

Я написал основные проблемы при чтении с графика. И это только самые очевидные. Дыры - это не проблема, т.к. обрабатываются точно также. Плюс удобство работы вызывает сомнения, т.к. чтобы эта конструкция работала необходимо держать открытыми графики. У меня скрипты могут сканировать до 1000 инструментов на разных ТФ - предлагаете все это открывать, наносить индикаторы. Терминал умрет первым.

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

Если думаете, что getCandlesByIndex не требует ожидания и проверки, что данные есть, то ошибаетесь. Точно также требует. Да, если скрипт запускается уже после того как терминал загрузился и "прогрелся", то можно ожидать, что данные уже есть. Но полностью исключает вариант работы скрипта "не выключаясь". А с таким числом требуемых графиков, терминал будет стартовать долго.

Это потенциально бесконечный цикл. Достаточно ошибиться в таге источника. Ожидание необходимо организовывать точно также, как рассматривали ранее. В этом плане getCandlesByIndex совсем ничем не отличается от CreateDataSource.

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

Так что причин использовать getCandlesByIndex не так и много. Хотя, конечно, если лень заниматься реализацией алгоритмов, то да, читаем и надеемся на лучшее.

Простая облигация - там реакции нет никакой. Для ОФЗ вроде есть реакция, но какая-то странная цифра в доходности требуется, чтобы цена изменялась 1000 и более. Что здесь тогда подразумевается под доходностью?

В релизе 12.6.0.53 указание доходности и выполнение команды "Задать цену" не приводит к изменению цены. Какую бы доходность не указать.

Конкретно для брокера Сбер - это так. Впрочем и для большинства брокеров, они ночью запускают регламентные операции на серверах.
У других брокеров просто нет SMS аутентификации, что позволяет автоматически восстановить соединение скриптами.

Еще забыл про такое решение https://github.com/devslm/quik-connector в качестве транспортной шины данных используется Redis

Вы уже определитесь ошибка ли это или нет. А то здесь уже обещали исправить https://forum.quik.ru/messages/forum10/message79698/topic2730/#message79698

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

Эта задача, похожа на задачу GC. Есть ссылка, её используют несколько потребителей. Соответственно закрыть ссылку можно только если счетчик использования 0.

Зачем закрывать, если он уже есть. Наоборот, просто вернуть существующий.
Если закрыть поток, который в кеше и используется, то будет ошибка обращения.

Здесь вопрос более тонкий. Кеш сделали и ладно. Я бы не стал полагаться на GC, все же запомнить уже заказанные потоки не сложно.
А вот закрытие оных уже вопрос. Я меня есть счетчик использования потоков. Т.к. один и тот же может использоваться много раз. И по мере того, как он перестает быть необходимым счетчик уменьшается, и если он 0, то вызывается Close. Дабы закрыть поток.

Но т.к. скрипт может быть остановлен принудительно, что закрыть все открытие потоки уже не всегда будет возможно. Как себя ведет терминал при таком закрытии скрипта - не ясно. Надеюсь, что есть внутренний кеш.. В древних версиях терминала (на ранней 7-ой, кажется) при заказе потоков без закрытия или вызова GC - терминал начинал есть память.

Если не путаю, то кеширования нет, так что это задача скрипта помнить, что уже заказано.

Субсчет в рамках счета - один квик, например в Альфе, Кит так. Разные счета (не ИИС к брокерскому - это в одном терминале) - это уже зависит уже от брокера. Сбер, например, недавно всех загнал в один терминал. У меня в Сбере два брокерских счета - в одном терминале.

У qluacpp есть форк https://github.com/Arech/qluacpp2

Правда тоже надо пилить напильником. В данном случае проще написать логику через dll на Lua C API.Но если все же смотреть на TCP, то тот же QuikQtBridge (https://github.com/eSKond/QuikQtBridge) написан на С++, правда с использованием Qt (для сетевой части). И он мне больше нравится, чем QUIKSharp, т.к. у оного сервер, по факту, написан на Lua. Если задача построить только серверную часть, то можно и взять только её.

Решения через Socket уже есть: QUIKSharp и QuikQtBridge. Еще есть StockSharp, но много нареканий на него.
Также есть RPC вариант - quik-lua-rpc
Был еще прямой интерфейс на c++ (но уже давно не поддерживается): qluacpp

По названиям легко найдете репозитории.

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

А так - Anthropic Claude, если есть доступ. Если нет, то OpenAI с их ChatGPT. Если и к ним нет, то и DeepSeek сгодится, если правильно вопросы задавать.

Не зная какие это сделки нельзя сделать вывод о изменении ОИ. Если сделки между новым и выходящим контрагентом, то ОИ не изменится. Да и 400 контрактов - это что-то мелкое.

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

Если задача показать разные методы, то проще дать ссылку на статью, где все они формализованы. Сейчас все разучились искать, так что я прямо обратно в 94-ом, когда интернет был набором каталогов с ссылками.