Доброго времени суток!
Проблема следующего характера. Мною были написаны несколько индикаторов (кстати на форуме остались актуальные сабжи от моего ника). Индикаторы работают нормально, но при написании скрипта с помощью этих индюков, скрипт не хочет оптимизироваться. Опять же при подключении этих же самых индюков в визуальном редакторе и описании логики входа\выхода с помощью кубиков все отлично оптимизируется. В своем скрипте индюки дергаю так же как в сгенерированном, параметры присваиваю так же, не могу понять в чем проблема. Прошу помощи у знающих. Все необходимые доки внизу

У меня показывает в первом и во втором случае ошибки, в ртс комплекс пишет об индексах за пределами диапазона.

А будьте добры скрин ошибки, пожалуйста

А, я же свои библиотеки не покидал) Приеду с работы докину)

Скорее всего путаница с параметрами в IContext.GetData Самый простой способ проверить так это или нет - убрать его и посмотреть что будет. Если скрипт оптимизируется нормально, значит я был прав и что фиксить понятно, ну а если нет - думаем дальше.

Ну, вроде бы так и есть.
IList<double> nSMFI = ctx.GetData("SMFI",
new[] { SMFIPeriod.ToString() },
delegate { return mfi.Execute(source); });
IList<double> nSDiv = ctx.GetData("SDiv",
new[] { SDivPct.ToString() },
delegate { return div.Execute(source, nSMFI););

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

А это относится только к шортовым позициям или и к лонговым? Просто вы написали для обработчиков для шортовым позиций, а вход в них закомментирован

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

Просто не первый раз с этой проблемой сталкиваюсь, в этот раз решил разобраться)
Ведь как так может быть, чтобы скрипты были практически идентичными со сгенерированным, а работать не работает

Спасибо Вам ОГРОМНЕЙШЕЕ. Вы были совершенно правы. После замены массива в GetData с:
IList<double> nSDiv = ctx.GetData("SDiv",
new[] { SDivPct.ToString() },
delegate { return div.Execute(source, nSMFI););
на:
IList<double> nSDiv = ctx.GetData("SDiv",
new[] { SMFIPeriod.ToString(), SDivPct.ToString(), source.CacheName },
delegate { return div.Execute(source, nSMFI););
всё заработало.
Буду очень признателен, если вы поможете найти информацию по правильному кэшированию, чтобы избежать подобных ошибок в будущем.
Если кому интересно, сбрасываю архивы обработчиков (библы по известному пути в папке debug)

Допустим у нас есть скрипт с двумя скользящими средними. Мы запускаем оптимизацию, где для каждой скользящей подставляется 10 разных периодов. То есть всего скрипт будет пересчитан 100 раз и, соответственно, каждая скользящая подсчитана по 100 раз. При том что их всего 10 разных. GetData позволяет избежать повторного расчета сохраняя данные в кэш и извлекая их оттуда при необходимости, что гораздо быстрее их повторного расчета. Для того чтобы определить, что нужный индикатор уже рассчитан и сохранен программа ищет в кэше данные с совпадающим названием индикатора и параметрами его расчета. Если вы укажете не все оптимизируемые параметры от которых зависит расчет индикатора то при оптимизации тслаб будет подставлять неверные значения индикаторов, что сделает оптимизацию бессмысленной (так было у Вас вначале). Если указать лишние параметры, которые оптимизируются, но не влияют на расчет индикатора, то это снизит эффективность использования GetData. В предельном случае, если туда напихать все оптимизируемые параметры он будет даже чуть тормозить работу.

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

По поводу source.CacheName. Не знаю что это такое. Наверное, это имя по которому программа определяет, что к какому скрипту относится кэш. Указывать в качестве параметра его не надо.

Ещё раз, спасибо Вам большое за полный и понятный ответ.
Вы все правильно поняли. И я теперь тоже все правильно понял) Впредь буду опираться на данную инфу.
По поводу source.CacheName. В документации это свойство описано следующим образом:
"Уникальное имя для кеширования в методе IContext.GetData"
При вставке оного опять же руководствовался сгенерированным скриптом, где при вызове GetData помимо периода SMFIPeriod и параметра SDivPct, указывался ещё один элемент "Источник1". Поэтому посчитал нужным где то выдернуть название источника. Решил, что это свойство как нельзя хорошо подходит. Исправьте, если это не так

Был рад помочь


Без него оптимизация отлично работает. Больше мне по этому поводу сказать нечего.

цепляйтесь может сюда:
https://github.com/tslab-hub/handlers

dll конечно всегда приветствуется для людей, кто работает только в редакторе и не умеет программировать совсем. Желательно оформлять в эту ветку с кратким описанием http://forum.tslab.ru/ubb/ubbthreads.php?ubb=postlist&Board=26&page=1

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



Я уже успел написать с добрую дюжину индикаторов, но в силу ограниченности документации и своего перфекционизм а, пока не могу их выложить. Это связано как с тем, что коды некоторых из них ещё не до конца причесаны, так и с тем, что остались открытыми вопросы по созданию индикаторов. В частности следующие:
- В топике http://forum.tslab.ru/ubb/ubbthreads.php?ubb=showflat&Number=84647#Post84647
Мне так до конца и не ответили, что нужно сделать для того, чтобы при создании системы через API в блок Внешний скрипт не нужно было закидывать пути к созданным мною индикаторам (обработчикам), а чтобы ТСЛаб сам подгружал их. Ибо получается совсем неудобно.
- В топике http://forum.tslab.ru/ubb/ubbthreads.php?ubb=showflat&Number=78390#Post78390
Последнее сообщение от меня, ответ на которое я, опять же, не получил. Суть вопроса была следующая:
Можно ли добавить описания к своим кастомным индюкам, как это реализовано в стандартных. Скрин с примером прилагается в ответе. Имхо для перфекционистов очень приятная штука) И позволяет ли API сделать ли это в принципе? Насколько я понял, это реализуется атрибутом, схожим с [HandlerName]([HandlerCategory]). Хотя, вполне возможно, я ошибаюсь)
Вроде пока все
Если решу вышеописанные проблемы, как только появится время все закину.

И ещё по поводу топика с индикаторами (http://forum.tslab.ru/ubb/ubbthreads.php?ubb=postlist&Board=26&page=1)
Я никогда не иду лёгким путем, и решил все интересные мне индикаторы написать самостоятельно. Если буду закидывать их в этот топик, будет шанс дублирования. Это ведь не страшно?