Столкнулся со следующей проблемой. Есть скрипт, работа которого основана не на исторических данных графика, а на фактических входах и выходах. В настройках скрипта стоит:
Макс. кол-во дней = 1.
Когда скрипт работает внутри одного дня - все ок. Но если состоялся переход на следующий день с открытыми позициями, агент как бы закрывает виртуально закрывает открытые позиции и открывает текущей ценой (по факту закрытия и открытия позиций не происходит). Данная ситуация ломает логику скрипта. Какие могут быть оптимальные способы обхода этой ситуации?

Сам собой напрашивается вариант, увеличить максимальное количество дней или установить нужную «дату от». Но этот вариант меня не очень устраивает, так как скрипт работает на секундах и опасаюсь что начнутся проблемы с нехваткой памяти.

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

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

Выглядит как баг. Напишите в тех поддержку.

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

Vil, понятно, что бар открытия меньше чем 0 быть не может, но цену входа же должно корректно показывать даже если она вне истории агента? Она же по кэшу сделок определяется?

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


Я использую секундный график. Т.е. для одного торгового дня нужно устанавливать 50 400 баров. Торговых дней может быть до 60. В данном случае вполне устроит настройка "Дата от", но весь вопрос работоспособности агента с 3 млн. бар истории, при условии что таких агентов более чем 1. А в целом, мне кажется немного неправильным подход грузить данные за длительный период, не для анализа этих цен, а просто что бы система корректно учитывала фактическую цену входа.

Да, это ограничение присутствует, если бары не загружены, то взять данные агенту неоткуда.
https://blog.tslab.pro/pages/viewpage.action?pageId=10748110
в самом конце статьи.

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

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

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


За ссылку спасибо, теперь понятно что это фича, а не баг)

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

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

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

Если вы выставите минутный тайминг, и будете использовать условные заявки, то ПОМЕНЯТЬ условие совершения сделки вы сможете раз в минуту, а отслеживание его будет идти непрерывно.

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

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

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

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

Я не сталкиваюсь с проблемой времени расчета. На самом деле проблемы на данный момент нет, есть опасения что она может возникнуть. Как я уже писал, я использую секундный тайминг, потенциальное количество дней в агенте - 60. Памяти 2 Гб. 2 агента отработали 5 дней, соответственно с историй 5 дней. Работают другие агенты с однодневной историей. Пока памяти хватает. Весь вопрос: что будет дальше.

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

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

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

Вопрос поднимался. Запись в базе знаний - отражение ответа.
База знаний - в принципе, отражение всех насущных проблем.
Пока не полностью, далеко, заполнена, но потихоньку делаем.
Если точнее ответ о проблеме: "перелопатить всю программу". В общем, пока не решаемо текущими средствами и пока будет так.

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

Пост старый. многое, что изменилось.
Например, база данных переплелась тесно с документацией.
Задайте вопрос, что именно Вас интересует.

речь вот про этот кусочек обсуждения