Доброго времени!
Уважаемые форумчане, поясните мне, пожалуйста пару моментов:

1) Согласно документации периодически (по окончании бара, по тику, или еще по-разному) вызывается пересчёт. В этом пересчёте дёргается Execute() задействованных скриптов. Казалось-бы логично, но почему абсолютно во всех примерах кода я вижу, что в этих Execute-ах расположен цикл вида "for (int i = 0; (i < barsCount); i++)" ? На каждом тике (или баре и тд) выполняется обход всей имеющейся в распоряжении истории? Я бы понял, будь то однократный вызов Execute на обход файла истории - прочёсываем историю, анализируем, расставляем покупки/продажи. Но ведь этот же скрипт идёт и в бой? И там, в бою, он будет постоянно обходить все имеющиеся в памяти бары?

2) В продолжение предыдущего вопроса, в том же цикле, встречается строка вида "source.Positions.BuyIfGreater(i + 1, 1, high[i], "LE");"
Как это воспринимать? Мы пытаемся создать отложенную заявку... на i+1-ом баре? Но он ведь уже история? Из всех баров [0..barsCount-1] только один бар существует сейчас, остальные - история. Мы пытаемся создать отложенный ордер в истории? Постфактум?

3) Как подать отложенный ордер Сейчас? Не на каком-то i-ом баре, жизнь которого, может быть, три дня как закончилась,
а именно сейчас?

Спасибо.

1. Потому, что эта история меняется каждый новый пересчет. Создать скрипт без цикла возможно, но это будет очень специфическая вещь без работы с историческими данными.
2. i+1 это текущий бар, т.е. тот которые еще не закрыт.
3. Точно так же как написано. i+1 Все будет работать. Заявка на истории не выставиться. При первом запуске может возникнуть виртуальная позиция.

1) Я прекрасно понимаю, что для нормальных стратегий требуется информация по нескольким предыдущим барам. Но почему во всех примерах идёт цикл по Всем барам?...
...Т.е. если в настройках указано "пересчёт после каждого бара" то при каждом Execute source.Bars.Count будет увеличиваться, и, как правило, на единицу?
Если, пусть тупо-банально, хочу покупать/продавать на пересечении МАшек, то можно без цикла делать

IList<double> sma_fast_arr = Series.SMA(source.ClosePrices, FastPeriod);
double sma_fast = sma_fast_arr[sma_fast_arr.Count - 1];
double sma_slow = ...

и, исходя из этих sma осуществлять покупку/продажу?

2) i+1 -й? Или [barsCount+1]? Или [barsCount]? Или [barsCount-1]? Какой из них в прошлом/будущем? ))

3) Зачем вообще в методе source.Positions.BuyIfGreater есть поле barNum?

4) Как работает конструкция вида? :
IList<double> high = ctx.GetData("Highest", new[] {HighPeriod.ToString()},
delegate { return Series.Highest(source.HighPrices, HighPeriod); });

Система единожды вычисляет Series.Highest и далее юзает их, что повышает скорость оптимизации? При этом каждому такому кешу задаётся уникальное имя с параметрами. По этим имени и параметрам при следующем обращении кеш поймёт, что обращаются к уже посчитанной последовательности, пересчитывать её не надо, и выдаст готовое? Но на следующем тике имя и параметр HighPeriod не изменятся, тогда как закешированные результаты будут устаревшими, поскольку изменились source.HighPrices. Как и по каким признакам система делает выводы, что надо юзать закешированное?

Еще раз спасибо

По всей видимости, этот пересчет организован, чтобы на одном и том же скрипте можно было и тестировать, и реально торговать. Но, если честно, тоже возник вопрос о необходимости полного прогона в реале
http://forum.tslab.ru/ubb/ubbthreads.php?ubb=showflat&Number=69806#Post69806

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

Кстати, в том же самом MT4/MT5 сие реализовано куда внятнее. Скрипт оперирует исключительно с "текущим моментом", а система в процессе оптимизации подаёт скрипту тики так, что тот думает, что проживает реальную историю.
А в TSLab, скрипт, значит, сам должен побарно скармливать себе историю в цикле.

Но вопрос закрыт! Благодарю за отзывчивость!

Правильный вариант понять и простить ))) Не все так страшно, на рабочем скрипте ставят ограничения количества баров и это самое i=0 будет именно там где надо для правильной работы, а не больше и всегда будет правильный индекс вне зависимости от того сколько баров есть. И кстати не всегда используют циклы с 0 индекса. Если есть обращения к предыдущим свечам, типа [i-3], то начинать надо с 3 или еще дальше если очень хочется.
А В GetData данные есть только на текущем пересчете и на следующем баре их уже не будет поэтому проблем с устаревшими данными нет.

Неужели к 4-му десятку я таки дорос до форумов, на которых реально просто берут и отвечают на вопросы, пытаясь понять и помочь )

Тут главное, чтобы вопросы совпадали)))

Вставлю свои 5 копеек.
1) Уже верно ответили, перебор истории больше нужен для универсальности кода. И в тесте и в реале он работает. В реале просто уменьшаем глубину истории и все дела.

2) История важна для расчета индикаторов например. Поэтому в реале тоже придется иметь бары и рассчитывать по ним индикаторы.

3) История важна чтобы ваши действия основывающиеся на анализе прошлых покупок и продаж работали. Если не будет анализа истории то не будет и решения на текущий момент.

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

5) самый главный пункт - расчет обычного скрипта с адекватной длиной истории это 4 мс. Если это много, тогда вы выбрали не ту платформу для торговли. Вам надо идти писать свое HFT. Не нужно оптимизировать по скорости то что итак быстро работает.

Работаю на минутках. Т.к. в ТСЛабе реализована не событийная модель (как в СтокШарпе, например), а итерационная, то это принципиально. Это для того, чтобы пораньше (на следующей свече) выставить стоп.
Так вот, 1000 минутных свечек обрабатывается от 50 до 150 мс. При этом не скажу, чтобы были слишком тяжелые вычисления. Да и комп не самый слабый: i7 с 16 Гб ОЗУ.
Один из скриптов поглощает около 5000 минуток. Обработка около 1000 мс.
Всего скриптов около 50
И из того, что используется на истории, около 80% в реале не нужно
Так что оптимизация моих скриптов для боевой работы, думаю, неизбежна)))!

Интересно что за 50 скриптов то торгуют, понимаю там 15-20, но 50!!!

А что тут особенного?
Торгую шесть бумаг (только ликвидные фьючерсы)
И на них две идеи. А все остальное - это лишь варианты исполнения, хорошо сглаживающие эквити

Тогда понятно, поэтому я и сказал что понимаю 15-20

Вот как бы оптимизировать нужно не число баров а логику ваших скриптов. С чего там 1000 мс пересчет то? Даже голимая обработка тиков за пару дней минуток не даст такой величины. Оптимизируйте свой код и будет работать 10 мс в пределе.