Потоковые и последовательные данные. Ошибки теста.

Доброго времени суток.
Вопросы по потоковым и последовательным данным. (База знаний)

1) Как настроить пересчет скрипта из кубиков, чтобы исторические данные использовались последовательно, так, как они поступают в реале, бар за баром?
2) Где указывать тип обработчика для скрипта на C#?
3) Можно ли в оптимизаторе запретить использовать данные потоком?

При использовании в стратегии индикатора на C#, например ZigZag, результаты потоковой обработки отличаются от последовательной.
При последовательной обработке сигнал перерисовывается, а при потоковой учитывается только конечный сигнал, когда он окончательно определен (предрассчитан при потоковой обработке).
В итоге результаты расчета тестера существенно отличаются от реала. По сути при потоковой обработке идет заглядывание в будущее. Пример "грааля" на потоковом зигзаге во вложении.
Зигзаг взят с этого форума (Handlers2.1.zip). Можно взять любой другой.

ЗЫ: НИ В КОЕМ СЛУЧАЕ НЕ ВЫСТАВЛЯТЬ В РЕАЛ!

ДОБРОГО ДНЯ! Лучше бы конечно зеленую картинку прикрепили))))))
Батенька всея Руси Вы грааль нашли)))))(шучу). Выставил просто ртс и на тебе счастье он зарабатывает. Тут явно заглядывание в будущее и даже не зависит какие параметры я поставил в индикаторе, плюс комис сделан не маленький на РТС поставил 25(то есть 50 на сделку), все равно за прошлый контракт 300 тыс пунктов. + провел оптимизацию , которая выявила что в принципе НЕТ значений инДИКАТОРА, ПРИ КОТОРОМ СТРАТЕГИЯ БЫ ВЫДАВАЛА ОТРИЦАТЕЛЬНЫЙ РЕЗУЛЬТАТ за весь контракт. Тут проблема не с потоковыми или последовательными данными, тут проблема с самим индикатором!!! Я вам расскажу по своему опыту что если такую стратегию поставить на торговлю, то будет следующее, скрипт будет постоянно перерисовывать сделки, возможно даже будет их на каждом баре открывать и закрывать, так как будет постоянно меняться значение индикатора.
По моему мнению
1) не как, исторические данные скопом приходят.
2) вопрос к программистам, только в вижел студио вскрвать проект и смотреть.
3)нет. можно уменьшить количество потоков( это не к вашей теме)

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

ЗЫ: Это не стратегия, а пример. Там до стратегии еще ваять и ваять. Начиналось все с банального паттерна 1-2-3 на зигзаге...

ЗЗЫ: Зеленое во вложении, но толку-то...

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

2 ViL - я взял индюки с этого форума. И _все_ зигзаги (их там 4, кажется) заглядывали в будущее на истории. Как бы для зигзагов и кучи других индикаторов перерисовка текущего сигнала - норма. И для правильного тестирования хочется настраивать тестер на последовательную подачу данных. Хотя бы в режиме разового запуска, а не оптимизации.
Можно выкрутиться, анализируя последний сигнал (для зигзага если сигнал увеличился в ту же сторону, то это перерисовка), но на истории-то этот анализ не отработает. Как тестировать? Нужен режим тестирования, соответствующий реальности - последовательный.

Мне кажется, многие на эти грабли наступали и будут наступать. Как убедиться, что индикатор не перерисовывает? Тестировать на реале? Не интересно. Писать все индикаторы самому? Глупо. А был бы режим последовательной подачи данных в тест, и все было бы понятно сразу.

Полезный ответ техподдержки по типам обработчиков для своих скриптов на c#:

Если код кубика реализует интерфейс IStreamHandler, то это кубик с потоковыми данными.
Если код кубика реализует интерфейс IIValuesHandlerWithNumber, то это кубик с последовательными данными.
Кубик может одновременно наследовать два интерфейса, тогда он сможет работать с потоковыми и последовательными данными.

Пример такого кубика:
https://github.com/TSLab-Dev/Handlers/blob/master/Position/HoldSignalForNBars.cs

Вам нужно проверять в скрипте, что зигзаг уже нарисован.
Т.е. с момента формирования зигзага прошло такое количество баров, которое в зигзаге или фрактале идет как параметр Баров справа.

2 ViL. В ЗигЗаге немного другие параметры. Но речь не об этом. Как сделать, когда я уже понимаю, что индикатор перерисовывается, я придумаю. В частности на ЗигЗаге, если текущий сигнал в ту же сторону, что и предыдущий сигнал, то это перерисовка, и менять хранимые значения предыдущих вершин не надо. Беда в том, что я на тесте не вижу перерисовки и не знаю, что надо построить стратегию иначе. В результате будет убыток на реале.
Вопрос в корректности тестирования. Получается, что я не могу доверять тестеру, поскольку часть сигналов потерялась (в данном примере). Stan прав - в реале будет открывать и закрывать лишние сделки, полагаю ни у кого сомнений в этом нет.
Я, например, не знал, что мой тест ЗигЗага будет кардинально отличаться от реала. Я, как пользователь, хочу тестировать наработки, точно зная, что именно так они отработают и на боевом счете. И при этом совершенно не имею желания угадывать, корректен мой тест, или нет. Мне казалось, что это очевидно. По сути у меня сейчас нет инструмента, чтобы убедиться в корректности стратегии. поскольку тестер выдает неверные данные. Вот в чем проблема.

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

Разработчики написали, что не понимают смысла и пока не планируют. Попробую подискутировать с ними и объяснить смысл.
Индикаторы не заглядывают в будущее, а перерисовывают прошлое (что для прошлого, впрочем, и есть заглядывание в будущее). А тестер просто берет конечный результат расчета потокового индикатора, когда прошлое уже перерисовано.
Я поставил на реал прорисовку без совершения сделок. Получилась интересная картина. Индикатор перерисовался в прошлом (сместилась текущая вершина ЗигЗага), и Обновляемое значение на основе ЗигЗага тоже перерисовалось! Т. е. в скрипт каждый раз подается вся история инструмента (согласно настройкам, конечно), и весь расчет идет снова. И обновляемые значения пересчитываются каждый раз. Надо понимать, что каждый вызов в скрипт приходит пачка баров, и результаты прошлой работы скрипта мы без специальных средств не видим, и какие там были значения индикаторов - не знаем.
Итого. Надо как-то научиться отличать перерисовываемые индикаторы от "ТС-Лаб-совместимых". ЗигЗаг для совместимости надо переписать на вывод всех сигналов, в том числе и "устаревших", и работать с этими сигналами на кубиках.

Ну если разработчики пошевелятся, то легко смогут сделать такой инструмент. Его смысл - автоматизированно найти в скрипте мину заглядывания в будущее (модификации прошлых расчетов по новым данным). Это был бы инструмент выявления брака в торговой стратегии и улучшения её качества.
Анализировать работу по сделкам - более универсально, поскольку можно и из "формулы" будущее подглядеть. Но по тому же принципу можно сравнивать результаты расчета и конкретного, указанного пользователем, индикатора. Это стало бы хорошим дополнением к анализу и способом выявить какой же индикатор в скрипте "косячит". Не нужно опускаться к деталям реализации индикаторов (потоковые они или нет), нужно анализировать изменение результатов их расчёта по мере расширения входных данных вправо.

Если речь идёт о том, чтобы прогнать в Лабе свою Стратегию barsCount раз, добавляя в неё по одной свече, как имитация работы в Агенте, то такая возможность есть. Делал такой кубик на заказ. С помощью метода recalc() вызываете пересчёт своей стратегии barsCount раз, а на выходе выдаёте ISecurity, которое каждый раз на 1 бар длиннее. Т.е. сначала выдаёте один бар, потом два бара и так далее. Но здесь много подводных камней и ограничений. Но в принципе, такое возможно.