Нужно при тестировании на истории, сделки, которые по факту оказались на минимуме/максимуме свечи, исключить(как будто их не было). Иначе узнать исполнился лимитный ордер или нет невозможно. Хотябы отменить из расчетов задним числом.

а вы их просто не совершайте

Программа при тестировании считает все лимитные ордера исполненными если была такая цена. На самом деле в жизни они исполнятся не все(те, которые оказались по цене максимума/минимума). Очередь же. Когда она на истории все прогоняет, она не может вернуться на одну свечку назад и проверить гарантированно ли исполнилась сделка, тоесть была ли цена хотябы на один тик лучше чем она входила.
И еще вопрос tslab при торговле лимитные заявки отправляет сразу в стакан? Например тейкпрофит ЦенаВхода+50 отправится в момент открытия позиции или только когда уже будет ЦенаВхода+50?

Лимитка есть лимитка она пойдет в стакан. Условная нет.

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

Вообщето срок действия лимитных заявок до 24-00, то есть если даже сразу заявку не взяли, она все равно будет в стакане до конца дня ждать исполнения. Разумно было бы на тесте исключить сделки на максимумах\минимумах свечей без последующего повторного тестирования этого уровня в течении торговой сессии

Самый простой вариант, если это конечно текстовые файлы, обрезать минимумы и максимумы в самом текстовике.

так же есть блок "обрезать".

Хотел ответить то же самое, но не смог так красиво сформулировать )))

Не понимаю суть проблемы. Неужели настолько часто входы совпадают тютелька в тютельку с хай/лоу, что из-за этого нужно городить огород? ИМХО учесть в комиссии вместе с проскальзываниями и прочими неприятностями с запасом, да и все дела.

Лимитки и используются, чтобы без проскальзывания. какое оно получится в реале неизвесно, а на 10000 сделок. даже 1 лишний тик даст 200000 пунктов. Тоесть тестирование при таком количестве сделок с проскальзыванием ниочем не скажет, потому что невозможно определить справедливое.

Сначала покажите мне 10000 попаданий тик в тик на хай/лоу
(Увидеть и умереть ),
тогда может быть поговорим сколько это будет пунктов и о других интересностях, с этим связанных.

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

Кстати, я и не говорил чисто о проскальзывании, а говорил о сумме "комиссий, проскальзываний и прочих неприятностей".

)Сумма комиссий закладывается на каждую сделку а не только на те которые по факту окажутся на экстремуме, потому что в момент когда цена подошла к лимитке невозможно определить возьмется она или нет. Тоесть на тестировании придется навешать на каждую пунктов по 30 и на вход и на выход и так оно и посчитает, а это нехилая разница. И при реальной торговле если указать, что соглашайся на цену по хуже, то почти всегда(невозможно предсказать как часто)она на неё и будет соглашаться как только тронули нужную цену. Учитывая что числа большие это тоже все ухудшит. Поэтому при тестировани на большом количестве сделок нужно знать точную цену по которой сделка совершилась, а не плюс/минус. И торговать нужно так потом. Иначе заложенные примерности могут дать сумму, которой каждый был бы рад в качестве дохода. Пожадничаешь с закладыванием комиссии-потом в реале обожгешься, заложешь больше хотябы на один тик - выкинешь алгоритм после тестировании на истории, потому что этот тик это минус десятки процентов на контракт. Можно было бы и под маркет ордера устроить корректное тестирование на истории, но для этого нужны стаканные данные хотябы и все равно всего не учесть по какой цене исполнилась бы сделка в реальности. где то по лучше где то по хуже. Единственный выход это алгоритм торгующий строго лимитными ордерами, причем не догоняющими цену, а встречающими её. В этом случае можно быть уверенным, что если цена прошла сквозь заявку, то она принялась. Кроме одного случая - сделка на экстремуме свечи и последующее закрытие сделки до того момента как цена вернется к этой цене. Тоесть tslab при тестировании пишет- закрыл сделку(на экстремуме), открыл противоположную, и закрыл её в плюс, а на самом деле этого ничего могло и не случиться если бы не было сделки на минимуме. Я хочу сейчас протестировать как будто все сделки на краях взялись и второй раз как будто все на краях не взялись и посмотреть результаты. Реальность смоделировать я не смогу, потому что там некоторые возьмутся а некоторые нет и невозможно предполагать какие именно, но хоть так. А все остальные риски типа технических сбоев, я буду решать потом, а не закладывать их в комиссию на каждую сделку. Это не объективно, они могут неделю не случаться. А всякие армагеддоны, когда цена в момент падает на тысячи пунктов, робот все равно не потянет даже маркет ордерами. не успеет. Здесь надо понимать, что какой бы он быстрый не был, а он не особо такой, он все равно видит тоже только прошлое, если цена уже какая то, то она уже такая, как бы он не торопился. Это уже надо решать адекватным к капиталу объемом позиции.

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

Если вы всё же считаете, что этот пунктик (именно тик-в-тик по хай/лоу) для вас очень критичен и вы хотите учесть его только так и никак иначе - см. выше совет ra81. Он вам сразу сказал что делать.
Но я всё же повторюсь - это стрельба из пушки по воробьям.
Средства ТСЛаба позволяют вам в этом легко убедиться - вместо объяснения элементарного тем, кто это и без вас знает, организуйте в алгоритме подсчет количества точных совпадений ваших лимиток с хай/лоу. Ни разу не удивлюсь, если их окажется 2 штуки на 10 лет теста. Из них одна у хорошего брокера сработает. А одной на 10 лет легко можно пренебречь.
Утрирую, конечно.

Да часто это случается на малеьких таймфреймах. Все равно не актуально уже. Я буду ждать версию 1.3. Там прочитал будет какая - то событийная модель вместо расчетной, то что сейчас мне не подходит ни для тестов ни для торговли. Оно даже не понимает, что открыть лонг, потом открыть шорт - это законченная сделка закрытая купил/продал, а не две открытых, которые еще надо пытаться закрыть. У нас логика с tslab не совпадает))))) У нас -это любой брокер, любой терминал брокера, биржа и я.)))

Я не думаю что в 1.3 вы сможете купить и продать и получить позицию 0. Так же будете открывать и закрывать позицию как и сейчас. Если вы хотите работать от ордера а не от позиции, то изучайте API, там есть возможность ставить ордера самостоятельно. И тогда уже все будет так как вы хотите.
Событийная модель просто ускорит скальперские стратегии под ТСЛаб и не более того. Для большинства пользователей особой разницы не будет. Только для любителей тиков и стаканов.

По поводу логики - посмотрите метатрейдер. Там тоже работа от позиции а не от ордера. Открыл позицию и закрыл позицию.

У меня проблема с торговлей возникла. фик с ним с тестированием. Суть в том, что при лимитных заявках тслаб вообще не понимает сколько у него купили после закрытия свечи если не настроить чтоб по рынку выходил. Тоесть была цена, позиция открыта - значит пропущенный выход, значит требуется вмешательство и торгуя на минутках такое несколько раз в час может быть, как бы кто не думал что это не так. После такой ошибки надо выключать агент, и терминалом брокера закрывать позиции, потом я делаю новый агент и он у меня торгует как бы с нуля, понято что вся история теряется, но если этого не сделать, то ошибка накапливается и тслаб может уже что угодно делать. думать что у него шорт, хотя позиций вообще нет, и так далее. Хорошо терминал брокера есть. А происходит вся эта бяка потому что - раз цена была, значит взяли все мои контракты. Можно в API такую логику работы исправить? Я думаю что нет, давно бы нам кубики уже бы сделали с обыкновенными лимитными заявками, а то при некоторых раскладах получается так, как будто их и нет в программе вовсе этих лимитных заявок.

Сейчас вот сижу. И выкинуть жалко в плюс же торгует. Но как она начинает заявки выставлять при неполном взятии какойто даже и разобраться не могу)))))))))))))))

Ожидать исполнение поставьте и будет ждать исполнение.
Блоки открытие лимитными заявками давно есть, см. во вкладке "позиции".
Если ошибки с позициями, переименовывать агент не нужно, есть кнопка "Забыть текущие ошибки".

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

Финансовые взаимоотношения у торгующего не с программой, а с брокером и биржей и в случае чего, его объяснения, что мол мне моя программа показывала что у меня незакрытый лонг в 100 контрактов, с вами она вообще не сверяется на эту тему, но она же показывала, никого не будут волновать. Если бы tslab не сбивался бы с подсчетом позиции сам, то тогда не было бы вопросов. Он не сбивается только с маркет ордерами где все однозначно - был сигнал - значит отоварили на всё.
Про метатрейдер и его тонкости я не знаю. Я ж не троллю, я хочу нужный мне продукт.

А если исполнение полное не наступит, то как долго ждать будет?

Если частичное исполнение произошло, то нисколько. Брокер присылает информацию об исполнении заявки, сколько бы не исполнилось.