Озадачился идеей написать модуль на C# для динамического расчёта размера позиций, ставил такие условия:
1. Чтобы могло работать и в лаборатории и в реалтайме
2. Чтобы могло отличить фьючерс от акции к примеру
3. Для расчёта плеча и размера позиции использовать критерий Келли.
Вот что получилось, прошу знатоков С# покритиковать.

ВНИМАНИЕ!!!
Обсуждается только реализация методики на C#, но не сама методика расчёта размера позы.
Особенно приветствуются советы по оптимизации быстродействия.

Во вложении PosSize.dll и PosSize.cs - собственно код модуля расчёта.
SMA_01.cs - пример применения этого модуля с двумя средними.

На текущий момент нет возможности проверить работает ли в реалтайме.

отличить акцию от фуча проще используя sec.SecurityDescriptions пошарьте в нем найдете интересное.
Так же у акций сейчас все не так прозрачно с новыми шаманскими T+2 порядками.
Ну и конечно же не учтена стоимость шага цены для фучей. Вы работаете от пунктов, что в реалтайме приведет к перекосу. Депо вы запрашиваете в рублях а расчеты в пунктах ведете.

Подскажите пожалуйста если использовать secRt.FinInfo.StepPrice - в чем она вернёт мне шаг цены, в пунктах или рублях и как он соотносится с тем что я получу от secRt.Tick?

secRt.FinInfo.StepPrice это стоимость шага цены а не шаг цены.
естественно и ответ на второй вопрос такой же.

То есть в рублях ?

в том в чем стоимость шага цены измеряется для данного инструмента. Для фьючерсов можно посмотреть на сайте moex.ru и обычно там в рублях. Для акций тоже в рублях. Смартком не дает такой информации имейте ввиду .

Доброго времени суток.

Выкладываю новую версию модуля. Исправленные функции PosSizeLongA и PosSizeShortA.

Решил пока с акциями не заморачиваться ибо все равно торговать планирую фьючи тока.

Что переделал:

Теперь я цену в пунктах привожу к цене в рублях. Таким образом образом единая система измерения стала.

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

Теперь самый ключевой вопрос.
Я получаю шаг цены в пунктах через secRt.Tick,
a стоимость шага цены в рублях через secRt.FinInfo.StepPrice.
Верно ли это?

З.Ы. Планирую торговать через Финам, интересно они эти данные присылают...?

З.З.Ы. исправил ошибку в расчётах, убрал деление на размер лота, так как цена уже сразу за лот а не за одну бумагу.

З.З.З.Ы. Ещё одну ошибку исправил в вычислениях теперь стопудово все ОК.

И все равно считает не правильно по сравнению с тем же реализованным в кубиках и Excel... По результатам скрипта C# всегда меньше лотов получается... Разница от 1 до 5.

не обязательно использовать secRt. Сейчас уже эти данные есть и в sec. даже в лаборатории если брокер подключен можно их считывать и использовать.

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

Почему так?
Опять же код прилагаю.

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

Вообще пока тест в лаборатории.

а по поводу условий, не совсем понял.
Просто функция (класс, метод?) вызывается из скрипта в котором ведётся торговля и рассчитывает размер рекомендуемой позы.

Как то так:
public TSLab.Script.Handlers.PosSize PosSize_h = new TSLab.Script.Handlers.PosSize();

//Размер позиции в лонг
IList<double> nLongPosSize = ctx.GetData("LongPosSize",new[] { source.Symbol},
delegate { return PosSize_h.Execute(ctx, source, AvProfit, KvAvProfit, GORub, SysPart,StepSize,StepPrise,true); });

Так же во вложении файлег с примером на двух средних.

CurentDepoLocal = (double)secRt.EstimatedBalance;

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

Возможно я не понял что значит "Значение оценки портфеля". Если так то выражайтесь яснее.

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

Кому интересно - в выложенном фале PosSize.cs:
PosSize - НЕправильно работает
PosSizeA - работает ПРАВИЛЬНО

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

Есть идеи в чем может быть проблема?

бегло пробежался.
1) непонятно ваше пристрастие к использованию кубиков в своих кубиков. Если у вас есть константа нафиг создавать кубик константы и потом его запускать чтобы чтото расчитать? Имхо половину кода надо просто взять и выбросить чтобы стало читабельно.
2) тормозит потому что у вас в торговом цикле на каждой итерации запускается ваш кубик который опять по всем свечкам пробегается. Отсюда и тормоза как мне видится. Либо делайте кубик по последовательной схеме где прошлые расчеты кэшируются, либо чето еще придумывайте. Как кэшировать прошлые расчеты смотрите в адаптивных индикаторах.

Отвечаю по порядку:
1. Вставляю код для расчёта констант из того что сформировал TSLab в папке Temp, исходя из того что, TSLab уж знает чего и как писать надо.
2.Ага в PosSize.cs не стоит использовать списки? Я правильно понял?

1) это я понял, но не всегда нужно брать и копировать. иногда все же нужно взять и улучшить.
2) без списков не обойтись. Просто нужно как-то сделать чтобы все работало быстрее.

Радион, можете подсказать в каких случаях нужно использовать

source.ConnectDoubleList и source.ConnectSecurityList?

Tslab то использует их то нет... не улавливаю логику.

А так же выкладываю последние результаты творчества, актуальная версия PosSizeB. Удалось сократить время вычислений на C# до 0.9 времени вычисления на кубиках... Ни ахти что, ожидал большего.

Радион - это видеокарта такая .
А два метода нужны для того чтобы обеспечить обновление графика в реалтайме а не только по пересчету. В общем и целом штука мало нужная. Сам никогда в коде не использовал и даже не рассказывал ученикам 8).

0,9 от кубиков это значит быстрее. Что уже отличный результат. Нужно ли еще быстрее? Тут просто нужно исходить из реалий. Главное чтобы работало ПРАВИЛЬНО!

Пардон, Родион.

Чтобы правильно, это главное - после каждого изменения в скрипте тестил, не изменились ли результаты.
Так что тут всё ОК.

А нужно ли больше? - Времени всегда не хватает особенно если оптимизация идёт пару дней.

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

Таким образом считаем Mission Complited. Если будет чего нового выложу или отпишусь в этой теме.

обычно много времени жрет обработка позиций. Это так. особенно их запрос на заданном баре.

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