Блок будет ждать пересечения заданных уровней хеджирования. Например, по дефолту он может прикрыть дельту начиная от 0.66 (по модулю). Если поставить Sensitivity=1, то выравнивание будет сделано только начиная от 1.



Допустим, у Вас есть Логическая Константа (или Логическая Формула). Блоком "Linked Parameter" эту константу можно привязать к блоку AutoHedge причем конкретно к его свойству "Align Delta" == "Ровнять дельту". Соответственно, если Вам автоматическое хеджирование уже не нужно -- передаёте в него false со своей формулы.

По сути, это получается некий эквивалент входа Permission у блока Buy Options. В каком-то смысле такой способ даже более универсальный.

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

Спасибо. Это что-то новенькое, попробуем...

Добрый день!

Я думал, что Автохеджер тоже относится к торговым блокам. Или это не так?

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

Что касается продвинутых алгоритмов хеджирования варианта вижу 2:
1. Написать другой блок хеджирования на АПИ
2. Реализовать условия совершения этих хеджирующих сделок на стандартных блоках. Но меня одолевают сомнения, что это будет так уж тривиально...

Дело в следующем.

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

Поэтому то и хочется "поиграть" с алгоритмом дельта хеджирования.

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

Наблюдал интересный эффект сегодня, как мне кажется, в тему обсуждения...

Запустил агента с Max Risk=60, Qty=10.
Реально при наборе позиции получилось =61. После чего агент для выравнивания позиции продал =10 (стало =51), затем купил =10 (стало =61), и так пару раз, и все со минусовым спредом, т.е. с потерями при каждой продаже.

Как выйти из такой ситуации?
Установил тут же Qty=1 и дождался пока позиций стало =60.

Вот вам "ручная" работа. Конечно, может настройки надо подправить, а может и алгоритм?

P.S. Установить Qty=1 это решение проблемы, казалось бы? А если Max Risk=1000 или больше, сколько времени потребуется для набора позиции?

Думается, что 1000 лотов таким алгоритмом никто работать не станет.

Если серьёзно, то ситуация известна. Почему не исправлена? Потому что для её исправления нужно вводить в блок 2 (ДВА!!!) новых входа. PutRisk и CallRisk. По смыслу они будут означать "Изменение риска при покупке 1 пута" и одного кола соответственно.

Надо ли настолько усложнять ситуацию в данном примере?.. Или делаем новый блок? Ваше мнение?

Ок. Давайте чтобы не плодить сущности сверх необходимого пока ограничимся отключением логики обработчика AutoHedge изменением его свойства через LinkedParameter...

Может еще какие нюансы обнаружатся? Да и решение - дозрело? Вам виднее, но я бы не спешил...

Добрый день!

Данную проблему с набором позиции "без перебора" можно было бы решить внешней логикой с алгоритмом, автоматически снижающим параметр Qty до 1 по мере приближения Current Risk к Max Risk.
Но к сожалению параметр "Объем заявки" не поддается управлению из вне, например, блоком Формула или Обновляемое значение.

Пытался прицепить к блоку Покупка опционов блок Связанный параметр. Прицепил.
Однако далее - тупик. Блоки Формула и т.п. не "цепляются" как надо...

Это что - принципиальный момент, что параметры не управляются из скрипта? Нельзя подправить?

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

Нельзя прилинковать формулу?
А ОЗ -- можно?
Или Константу?

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

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

В этом то и проблема данного опционного комплекта TSLab_2.0. Это недоступность параметров из под блоков типа Формула. Нельзя ничем управлять, фактически.

1. Выше упоминаемый пример. Нельзя управлять параметром Qty из под Формулы. А это дало бы МНОГО вариантов для решения серьезной проблемы при наборе позиции.

2. У меня в агенте центральный страйк рассчитывается блоком Формула. Хорошо, что блок Покупка опционов принимает эти значения.
Однако получить цену текущего опциона на график или опять в блок формула невозможно, т.к. у блока Один опцион - недоступен параметр Страйк для управления из под Формулы и т.д. и т.п.

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

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


P.S. Вы пишете: "...надо искать другой способ решения задачи...". Проблемы обозначены, и не одна. Давайте решать.

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

Данные вопросы, которые обсуждаем - это вопросы принципиального характера (я имею ввиду, типа управления Qty). Без их решения или тяжело обходиться, или даже невозможно.
Они больше разработчикам адресованы. Надо ли их отправлять в поддержку?

Что касается вопросов интерфейса внешнего вида и мелких глюков. То пока не них, с ними можно работать.

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

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

А здесь на форуме мы потрындели и разбежались. Никакого порядка и учета.

1. Насчет невозможно категорически не согласен: мы предоставляем открытый АПИ на C# с возможностью реализации любых Ваших самых фантастических идей в коде. Один герой написал свою библиотеку индикаторов. Около 200-300 блоков реализовал!



2. Если Вы считаете, что Вам кровь из носу нужен управляемый параметр Qty -- можете разработать свой блок дельта-хеджирования, который примет на вход ещё 3 параметра (риски путов, колов и текущий Qty).

Чтобы понять, почему Ваш запрос сложнее чем кажется, давайте вспомним программную модель ТСЛаб: Ваш скрипт получает массив баров и на каждом баре должен принять решение что он делает + расчитать индикаторы и т.п.

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

Теперь второй вриант: у нас идет рилтайм торговля. Мы именно сейчас вдруг решили, что Qty = 314 и этот параметр блока проживет ровно 1 бар. Можно проапдейтить параметр блока. Но только этот параметр будет применяться ко всей истории баров и при следующем пересчете опять поменяется. Получится не совсем то, что Вы бы хотели увидеть, верно?

Всё же мне неясно, зачем Вы хотите менять квант котирования. Учитывая, что заливать Вашу заявку будут случайным количеством лотов это несколько бессмысленное занятие.

Если речь идет только о том, чтобы избежать превышения MaxRisk, то мы уже обсуждали эту возможность (нужно добавить в блок 2 параметра с рисками одного лота колов и путов). Но Вы тогда сказали "не надо торопиться, посмотрим как пойдет".

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

Но согласитесь, что опционный модуль на сегодня не позволяет реализовывать полноценного торгового робота. Причем сложность алгоритма здесь не причем, простые операции нельзя выполнить.
По одной простой причине: НЕ УМЕЮТ БЛОКИ линейные и опционные обмениваться требуемой информацией. А "Голова", задающая алгоритм - это как раз набор линейных блоков (формула, ОЗ и другие)
Максимум что есть - "установить руками" и "посмотреть глазами" человека, торгующего в ручную.
Скрипт существенную часть этих параметров НЕ ВИДИТ - нет доступа к информации, блоки работают в разных измерениях. А соответственно и управлять как?. Когда то, чем надо управлять Вы заложили как параметр, доступный только человеку.

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

Повторюсь, приведу пример.
Отсутствие доступа к управлению Объемом заявки (Qty) приводит к тому, что агент не попав точно в заданное значение лотов (Max Risk) пытается в него попасть и - продает/покупает/продает/покупает... и т.д., и все с отрицательным спрэдом, т.е., сливает депозит до тех пор пока не вмешается человек (если он у монитора) - я оказался у монитора, увидел, остановил...
Если бы был доступен Qty для линейных блоков - простой алгоритм снижения объема заявки вплоть до 1 по мере приближения к Max Risk.
А самое главное таких алгоритмов можно перепробовать много, в случае чего, ведь переписал формулу с условиями и все. Нужно лишь один раз получить доступ к параметру и открывается простор для творчества. Понимаете мою мысль?

А Вы говорите: "...Если Вы считаете, что Вам кровь из носу нужен управляемый параметр Qty -- можете разработать свой блок..."
Спасибо за совет. Я же Вам предложил как вариант для обсуждения, а тут обиды...
Вы для чего открытое тестирование устроили? Я принял это всерьез, а мне говорят - фантазии...

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

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

Вы считаете разработку собственного алгоритма торговли фантастической идеей? Ценю Вашу откровенность.

Давайте все таки искать компромиссы и положительные решения... для общего блага.


P.S. По поводу обращения в "поддержку" - осознал, буду чаще туда обращаться.

1. Не обижаюсь. Напротив, очень ценю обратную связь, которую Вы мне даёте.

Попробую ещё раз переформулировать: разработка опционного робота -- это ожидаемо и приветствуется. В этом действительно нет особой фантастики. Под фразой "фантастические идеи" имел в виду сложные нетривиальные алгоритмы котирования и/или хеджирования. Именно они составят Ваше личное ноу-хау и будут фундаментов Вашего успеха в торговле опционами.

Обычно люди закладывают туда свои нюансы: "если Луна в первой четверти, то котируем вот так, а если новолуние -- то вообще позу закрываем" и т.п. У нас нет физической возможности все такие вариации учесть и реализовать.


2. Наша разговор немного потерял конструктив...
Поскольку "у каждой задачи есть простое, понятное, очевидное, неправильное решение", давайте придумаем правильное.

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