Приветствуем Всех!
Кто торгует через TSLab, знают о ситуациях в «реверсных» алгоритмах, когда необходимо переворачивать позу. Сначала выставляется закрытие для текущей позиции, далее открытие для новой. В большинстве случаев, конечно это происходит крайне быстро и без проблемно, но любая транзакция имеет задержки, пусть 100-300мс но все же задержки есть. Этого не избежать в принципе никак. Но можно перестроить алгоритм, таким образом, чтобы вместо закрытий позиций, были просто «задвоеные» заявки. То есть получается, открыли лонг, далее например открываем шорт +1 к лонгу.
В итоге получим просто перевесы в размере позиции, то есть лонгов 144 шортов 145, в итоге текущая позиция просто 1лот шорт. Это слегка не привычно с точки зрения восприятия, но главное избегаем двух транзакций!
Скрипт построен на фьючерсе ртс, индикаторов в принципе нет, простенький паттерн используется для демонстрации системы.
Так выглядит график при таком «фокусе»
Конечно если собрать в стандартном виде этот алгоритм — будет всего десяток блоков и минимальная логика, в случае ж с представленной идеей — все сильно усложнится)) нужно правильно контролировать лоты, уровни и тд
В данном случае главное понимать, фактических закрытий позиции нет, потому трактовать график эквити и таблицу результатов, будет сложнее.
Сам скрипт можно скачать и посмотреть уже на систему «изнутри»
Подписывайтесь к нам в телеграмм канал. Очень много полезной информации от реальных пользователей программы и практикующих трейдеров и программистов!
ну это помимо того тупого бага что выкачивает 1минутки через все сделки… а не просто 1 минутки в виде готовых баров… это прокатывает на 1-2ух бумагах… но когда надо загрузить минутки по 20-30 бумагам зараз да за пару дней… даже не за пару дней а часа за 2… карета превращается в тыкву… в одном ри 200000 сделок в день… и вместо 60минут*14часов=840 бар в день тслаб тужится надсдно выкачивая 200000 тиков...
ves2010, зато тиковая история — самая качественная из возможных.
Вдруг Вы завтра захотите использовать бары S12, объёмники или рейнджи? =)
ves2010, большинство русских брокеров (кроме itiCapital) не дают скачать историю минутных баров глубже, чем за 1 месяц. А накопленная на жестком диске история тиков позволяет восстановить историю баров на любую глубину.
Впрочем, не мне Вас учить. Возможно, поставщикам в ТСЛаб и правда было бы неплохо иметь настройку «не закачивать историю тиков» наподобие того, как это сделано для опционов в поставщике QuikLua...
С уважением,
Нужен просто кубик, который сможет одновременно закрыть одну позицию и открыть новую.
Название "Перевернуться по рынку", например.
Или более хитрый сценарий, когда нужно кровь из носу выйти из старой позиции сделкой по рынку и ОДНОВРЕМЕННО выставить ЛИМИТНУЮ заявку на открытие новой позиции. Можно назвать такой кубик "Закрыть по рынку и Открыть лимитником".
жесть какая-то. Откуда такие сложности с расчетом позиции? Неужели нельзя хранить данные о позиции в какой-либо переменной?
я, правда, не знаю как устроен расчет позиции в ТС-лаб, но у любого алгоритма должна быть своя переменная, в которой хранится текущая позиция, независимо от того, есть ли коннект с сервером или 220В в розетке компьютера.
я не понимаю вашего диалекта. Дельта/заявка. В чем проблема тогда?
Чего обсуждаете то? Есть позиция конкретного алгоритма, надо ее изменить, в чем вопрос?
Дмитрий Овчинников, про свою переменную всё понятно. Но раз платформа вводит понятие «Позиция» и рассчитывает определенные статистики по количеству закрытых позиций, средний профит, вероятность закрыть сделку в плюс и т.д., надо пользоваться.
Весь разговор крутится вокруг тонких нюансов в момент переворота из лонгов в шорты и обратно.
Кстати, смею напомнить, что решение озвученной проблемы можно (и нужно) получить путем одновременной параллельной отправки нескольких заявок.
Например, мне нужно котировать 20 тикеров двухсторонними котировками. в среднем на относительно спокойном рынке на каждом баре нужно переставить 5 заявок на новую цену. Сейчас эти 5 заявок пойдут последовательно и в сумме перевыставление этих заявок займет примерно 1 секунду (5 новых заявок + 5 команд на отмену старой заявки) * (100 мс в среднем при хорошем раскладе).
А должно уходить параллельно и одновременно 5 команд на отмену 5 старых заявок (100 мс) + 5 команд на выставление новых заявок по мере прихода уведомлений об успешной отмене старых.
То есть в сумме это должно занимать максимум 200 мс.
Понятно, если рынок галопирует, количество переставляемых заявок увеличивается кратно, а масштаб проблемы переходит в категорию «бедствие».
Кстати, если говорить о повышении эффективности программы было бы правильно ввести партиционирование файлов с сериями баров. Сейчас вся серия баров хранится в одном запакованном файле. Но чтобы с ней что-то сделать ВАМ нужно всё содержимое файла распаковать и положить в оперативную память.
Из-за этого программа становится неимоверно прожорлива по отношению к ОЗУ. А если Вы нарежете эти серию посуточно, как делаете это с тиками, то можно будет работать только с теми данными, которые действительно нужны Пользователю.
И разложить файлы с данными в отдельные подпапки по названиям инструментов тоже было бы правильно. Сейчас просто зайти в директорию с парой десятков тысяч файлов — уже само по себе мучение для операционной системы Windows...