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

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

Кубики экспорт (отправить) и импорт (принять) должны уметь связываться со всеми кубиками, формулами и т.д.

Сделайте пожалуйста такую возможность.

Пример: http://forum.tslab.ru/ubb/ubbthreads.php?ubb=showflat&Number=58716#Post58716

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

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

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

Просто пример идеи из другого кода.

const long mmfLength = 24L; const long mmfOffsetFrom = 0L; const long mmfOffsetBid = 8L; const long mmfOffsetAsk = 16L;
MemoryMappedFile newMmf = MemoryMappedFile.CreateOrOpen(("Local\\FoK_" + name), mmfLength);

//Непоследственно записываем данные в память
WriteDataToMemory(newMmf, from.ToCharArray(), bid, ask);
void WriteDataToMemory(MemoryMappedViewAccessor accessor, char[] from, double Bid, double Ask)

if(isStopping) return;

//Записываем новую строку в память
if(accessor.CanWrite) accessor.WriteArray<char>(mmfOffsetFrom, from, 0, 4);
if(accessor.CanWrite) accessor.Write(mmfOffsetBid, Bid);
if(accessor.CanWrite) accessor.Write(mmfOffsetAsk, Ask);

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

Создал опрос в предложить идею http://tslab.reformal.ru/proj/?ia=953801
Голосовалка это хорошо конечно, но как посмотрел нереализованные предложения висят на рассмотрении по 2-3 года!

Там есть фильтр, посмотрите, много реализовано.

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

А когда будут готовые хорошие кубики :?
или не будут и только за гроши :?

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

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

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

Поддерживаю. Из агента в агент, особенно из доски опционов надо в агент передавать греки и П/У. Нужно решение из коробки, поскольку в доску то не залезть самому.

Добрый день!

Здесь (в TSLab2.0 - опционы) вообще никуда невозможно залезть самому...

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

Работа, конечно, проделана большая, заделы оригинальные и перспективные, НО...

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

Выясняется, что:
1. Роботов (опционных) не построишь - нет доступа к параметрам позиции, ряду других параметров, необходимых для организации обратных связей и управления СТАНДАРТНЫМ роботом, нет возможности работы на "истории" - соответственно, нет возможности настроить робот и тд.

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

2. "Заточили" под ручную торговлю с автоматизацией сервиса - возможно это правильное, рациональное решение для начала проекта.
Руками, так руками...
Однако нет очень важного (если не главного) функционала - возможности торговать "руками" из агента. Я не беру в расчет агента "Опционная доска", а по типу менеджера заявок.
Представьте себе торговлю "вручную" с подключенным агентом, который "видит" действия трейдера и его позицию.
Когда в агента поступает такая информация, можно использовать практически весь арсенал TSLab для организации разного рода индикаторов, других средств автоматизации, ОБСЛУЖИВАЮЩИХ РЕАЛЬНУЮ ПОЗИЦИЮ трейдера.
Сейчас это недоступно...

3. И еще момент. Опционные стратегии бывают не тривиальными, особенно при хронически падающей волотильности, когда выгодней продавать и хеджироваться. Тут на форуме почитать - и кондоров строят и т.п. стратегии.
А визуализировать возможные сценарии и проверить что куда пойдет - все это можно было бы достаточно легко сделать арсеналом средств TSLab.
Можно было бы, если бы не то, что описано в п.1 и п.2

Поэтому и приходится за каждым "чихом" или формулой обращаться к разработчикам.


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

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

Вы про какую позицию? Про "позицию на счете"?
А зачем она каждому конкретному роботу?



Это голословно.
Если Вы торгуете руками -- Доски Опционов должно быть достаточно в большинстве случаев.
Там даже котировщик по волатильности есть.
Можете хоть кондор набрать, хоть "ёлку" какую-нибудь.

Мало? Ну, берем робота "Real trading"? допиливаем чего Вам не хватет (или спрашиваем нас) -- и торгуете дальше руками.

Причем в отличие от Доски робот RealTrading вполне реально допилить самому,
чтобы торговать даже календарные комбинации.
Имхо.



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

И как Вы будете использовать эту ценную информацию?
Что с точки зрения брокера позиция 0?



Для моделирования позиций сделан специальный робот "Static Analysis".
Вы с ним разобрались?
Написали мне чего в нем не хватает?



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

По крайней мере робота Buy vola Вы ещё тогда переделали до неузнаваемости.

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

В обоих этих случаях разработка по очевидной причине замораживается...

Уже сделано. Доступ к этому функционалу -- через API.
Почему через API? Потому что только Вы можете сформулировать что Вам надо для счастья.

Называется это "Глобальный кеш".
1. Создаём кубик на базе интерфейса IContextUses.
2. В методе Execute говорим:


Метод принимает 3 аргумента:
- key -- это строковый идентификатор сохраняемого значения (уникальное для всей программы имя)
В частности, это может быть имя Вашего кубика -- это Вы сами решаете что будет Вашим ключем.
- data -- тип object. То есть это ЛЮБОЙ объект в терминах C#.
Хоть коллекция, хоть список, хоть кот в сапогах.
- toStorage -- если true -- Ваши данные будут сохранены на жесткий диск (их для этого надо пометить как [Serializable]).
false -- значит значение хранится только в памяти.

Это был "Блок экспорта".


Теперь "Блок импорта".
1. Также на базе интерфейса IContextUses
2. В методе Execute говорим:


Метод принимает 2 аргумента:
- key -- это строковый идентификатор сохраняемого значения (уникальное для всей программы имя). То самое, которое мы обсуждали для первого блока.
- fromStorage -- если true -- Ваши данные будут считаны с жесткого диска, если их ещё нет в памяти в этот момент.
false -- просто возвращаем то, что есть в памяти.



Теперь сложности (почему пока что нет стандартного решения):
1. Вам нужно принять решение, хотите Вы иметь число для каждого бара или одно число на всю серию данных?
2. Что Вы будете делать при тестировании на истории?
3. Что делать, если потребитель и поставщик живут в разных таймфреймах?


ПС Передача чиселок между роботами у меня сделана на примере пары блоков HV -- GlobalHV; IvOnF -- GlobalIV.

А ещё если Вы случайно по ошибке сделаете 2 поставщика данных с одинаковым именем -- они начнут конфликтовать...

Один будет пихать в кеш массу, а второй -- скорость...

Добрый день!

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

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

В общем, все, что так много наработано в линейной версии TSLab 1.2 - ожидалось, что останется естественным образом и в опционной версии программы.

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

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

А что получилось на практике?
Если в линейной части есть практически полный набор функциональных блоков, из которых можно собрать МНОЖЕСТВО РАЗНЫХ скриптов, то в опционном наборе наоборот, Вы нам предлагаете НЕСКОЛЬКО ГОТОВЫХ АГЕНТОВ - "Buy Vola", "Опционная доска", "Static Analysis" и т.д.
Вы так и будете для каждого пользователя, каждый "чих" программировать?

А самостоятельно, как ни пытаюсь собрать до конца не получается - все время чего-то не хватает... знаете почему?
Потому что опционные "кубики" - это фактически запчасти от Ваших агентов.
Из них можно собрать только "Buy Vola", только "Опционную доску", только "Static Analysis" и все (ну может быть, с небольшими вариациями).

Ничего другого не соберешь!

Но, повторюсь, это только мое личное мнение... Жалко время идет, а мы где?

Абсолютно поддерживаю вышесказанное! Пришел Каленкович, вот они и сделали опционный скрипт именно для него. Все остальные в стороне. Причем абсолютно никаких пояснений по работе блоков... так... жиденькое описание, да пара видео в рекламных целях. КАК С ЭТИМ РАЗБИРАТЬСЯ?!
С таким подходом Вы далеко не уедете и пользователей больше не будет, а завышением цен Вы еще и старых отпугнете.