|
PureBytes Links
Trading Reference Links
|
Alex:
discovered a bunch of oddities in TS that I thought I'd share, since I
know many on this list still depend on TS on a daily basis.
Some are oddities, but many of your observations aren't oddities.
"inaccuracies" then :)
OHLC, it decides the internal order as follows:
the shortest O->L or O->H distance gets covered first, regardless of
overall market direction.
Yes, this is clearly documented in the TS2Ki language reference.
It isn't an oddity at all, but a sensible approach to determining
the order in which multiple trades get executed within a bar.
Naturally, you'll find exceptions to this behavior in real life. A
typical bar inside a trend will generally behave in that fashion,
however. TradeStation has no way of judging "overall market
direction" - that's your job, and that's why we have so many
indicators that attempt to judge direction. All TS can do is make
an assumption about the bar.
even looking at the close relative to the open will give you an
indication of market direction.
The method they've chosen is pretty arbitrary, and to my initial
investigations, quite sub-optimal.
Of course, being on a TS list, using TS, there's nothing you can do
about it. I mention it in passing, if you're wondering why systems that
are faster than your data might be misbehaving.
Short version: Don't trust TS to accurately estimate sub-bar signals.
If you have a stop and the day's open gaps through it, TS fills it AT
the open.
That happens in real life. Is that a problem? In real life as in
TS, stop orders become market orders the instant the stop price is
touched or passed by.
No, I left that in my list by mistake. Sorry about that.
This has major consequences for systems that depend on relative comparisons
No, it has major consequences for comparing a system in your
software vs TS. Over the long term, the errors will occur in
both directions and overall things should balance out. As I said
earlier, a strategy that's sensitive to small errors in precision
isn't a good strategy.
When it HAS mattered to me, I have compared two numbers as a
difference, and require the difference to be greater than some
epsilon like 0.0001.
If you're comparing an indicator with a previous value of the indicator,
you're going to run into these problems (using an epsilon is a good
solution to this).
If you're using fine maths to calculate number of contracts traded, or
entry/exit prices, you're going to run into these problems.
The whole thing depends on how wound up you're going to get about
individual trades being reliable or not.
I'm looking at thousands of trades on many markets over 20+ years so
these errors really jump out - and in some markets result in
ridiculously significant differences.
If you're only trading liquid markets with tight spreads & fine
increments (minimum market moves), trading often, you likely won't
notice any of these things. So, you know, people are welcome to go back
to sleep, nothing to see here :)
Setting max bars back to a large number doesn't ensure that the internal
calculations are done before that point, it just doesn't
START them any earlier.
Correct. MaxBarsBack is typically best left to TS to figure out.
But if you have a function or indicator that calculates its own
number of bars back (so TS can't tell from the constants how many
bars back it needs) you can set MaxBarsBack to tell TS when to
START calculating. And we all know that this works for something
like Average(), which will start out with the correct value when
MaxBarsBack is big enough, but XAverage() will still require even
more time to settle unless you initialize it to the Average() value
first.
Actually I'm talking more that if your system depends on referring to
earlier values of an indicator, then the first few bars AFTER the
MaxBarsBack'th bar will be incorrect. (although yes, the XAverage
example you give is a separate concern).
Eg, you have an Average(Close,15). You (or TS) set MaxBarsBack to say,
50. So, on bar 50, TS has more than enough data to calculate the average
correctly.
However, if your system refers to Average(Close,15)[X} (where X is any
number > 0), it will return ZERO.
To recap:
With MaxBarsBack 50, on bar 50, Average(Close,15) calculates, but
Average(Close,15)[anything] doesn't - even though there IS data there
that could be used.
So, if you want accurate signals, but you're referring to, say, 5 bars
ago, you actually need to wait until MaxBarsBack+5 before you can trust
anything that comes out of TS.
The XAverage settling is a completely separate nightmare, in this regard :)
Consider a current bar, which will contain prices at 0.05 increments
(107.80, 107.85, etc.). Typically your calculations of prices for
stops and limits will involve some floating point math, which may
result in an order to buy 1 contract at 107.83. TS will simply fill
the order the same way it does when price gaps past your stop - the
next available price that meets your order requirements.
oh yes, this is completely expected & reasonable. The point I raised
above was simply in the case of "odd data values" in back adjusted data.
cheers
Simon
|