I’m sure this is covered somewhere already but a search doesn’t tell me what i need to know: is there a maximum to the tick mode that PRC can deal with?
I’m working on an algo that is showing tick mode in excess of 10,000 on a 5m chart and the results are suspiciously good … which makes me think they are possibly not tbt ???
found the answer – forget i spoke
With regards to tick by tick, V10.3 I could do a 100,000 bar test with tick by tick data. V11, I can only do a 2,500 bar test? Is this right?
Out of interest, how would you know about those 2500 bars ? Did you count them ?
Possibly I don’t understand what you mean with “tick by tick data”. See attachment for how I interpret it. 1 bar (which is no bar but a spot) now is 1 tick. So you would need to count those, right ?
I could do a 100,000 bar test with tick by tick data. V11, I can only do a 2,500 bar test? Is this right?
No, on v11 we can do a backtest on as many bars as we want with tick by tick enabled. It was the same on v10.3.
The 2,500 tick by tick limit kicks in if on your Algo there are > 2,500 bars with TP and SL being hit in the same bar then you will get that tick by tick error message.
how many times your entry and exit got hit in the same bar.
It’s how many times TP and SL are hit in the same bar.
If entry and TP hit only in same bar (not SL also) then this would not add 1 to the Tick Mode column.
If entry and SL hit only in same bar (not TP also) then this would not add 1 to the Tick Mode column.
yes, correct – that’s what i meant to say … but, er, didn’t.
Hmm, just thinking this through for a minute, I’m working on a 2m algo on the DAX with a minimal SL of 5 points but TP of 1% … and I’m getting tick mode over 5000.
Seriously? 5000 times in 6 years where the price moved 1% in 2 minutes? That’s more than 3 times a day. I doubt if I’ve ever seen it happen once. 🤔
I agree!
Looks it’s counting hits on SL only?
Sounds like we need to ask PRT what is the definition a count increase in the Tick Mode column in the Oprimiser results?
https://www.prorealtime.com/en/contact
Ok, I have done that very thing, will report back if i get a reply. Obviously the important thing to know is if that number is over 2500 (for whatever reason) then your results will be skewed.
Very interesting. I was wondering what that tick mode number was on the optimizer window. And I thought that sometimes I could get more than 2500k bars of test with tick by tick too sometimes. I dont recall seeing that limit in 10.3 though. I wonder why there is that limit of 2500 bars with the open and close in the same bar? Is it to limit scalping activities/small trades? Not that I do that, bigger trades to beat spread are better anyway. Just interesting, if it has to read all the tick by tick data, why limiting same bar opens and closes is important, or how the occurrence of such events could strain counterparty systems.
I wonder why there is that limit of 2500 bars with the open and close in the same bar?
It’s not open and close in same bar, it’s as described on the link below …
tick by tick question
Hi GraHal, so, # of times TP and SL hit in the same bar.
TP as in?
Takeprofit
So if my code doesn’t have a TP in it at all, does that mean my tick mode should stay at 0 then?
Why am I having the issue with the tick by tick exceeding 2500 if I’m not using a takeprofit, as per your description from post 159777?
Interested to see the answer as per post 159846.
if I’m not using a takeprofit, as per your description from post 159777?
Description on link above is what I have seen stated by PRT (against v 10.3) either in a context message
or PRT Manual.
I agree the tick by tick mode defintion appears to have changed in v11 and I am also Interested to see the answer as per post 159846 .. I hope PRT answer soon!? Can’t be a hard one for PRT to answer surely??
