|
PureBytes Links
Trading Reference Links
|
OK, my brain has been cleaned and pressed, so let's see if they
got the wrinkles out...
Alex wrote:
> I thought there was this "update every tick" feature in TS,
There is. But it works for INDICATORS, not for systems.
And it's a real can of worms. Indicators can calculate stuff
based on the most recent "close" of the bar, but they can't
REMEMBER anything from one tick to another. Everything gets
forgotten and reset on the next tick. They HAVE to do that in
order for update-every-tick in realtime to produce the same
results you'd get in backtesting.
But that means you can't have any kind of side effects. Which,
of course, is exactly what systems do: side effects that do
minor little things like buy and sell. If you allowed UET in
systems, the results you saw in realtime wouldn't match what you
saw in backtesting. Not good. So TS doesn't allow it.
> Yes, I need to do the calculations on 1 minute bars. I'd do it on
> ticks if it was possible to do calculations like average and StdDev
> over time-lookbacks rather than bar-lookbacks. (I'm sure it's
> possible, but not easily implemented, and probably too slow once
> implemented.)
It's not that bad. It's a lot easier with the functions
available in TS2k and later -- e.g. you don't have to do your own
StdDev calculation. You can just store data points (1-minute
closes or whatever) in an array and call the array-based SD
functions. Averages are simple. You're an experienced
programmer, so you'd have no problem with the arrays &etc. And I
doubt it would be much slower, other than the unavoidable fact
that you're running the system on every tick. I.e. if you could
run 1tick/1min together, and used the built-in TS functions to
calculate SD/avg/etc on the 1min bars, it would be no faster than
if you calculated it yourself based on a 1tick chart.
> > Why wait until the data comes up? Just issue the order on every
> > bar until it's filled or cancelled. Or, since you're going to
> > do it on a 1tick chart anyway, who cares about limit orders?
> > You can do it yourself with market orders.
>
> I can't do that because the limit levels change on every bar, and
> the filter which determines whether a bar is "valid" for trading
> depends on the spread between the high and low limit levels for
> buying and selling, which changes every bar. Therefore I can't know
> whether an order should be placed until I'm looking at the bar as it
> forms.
Wait. You're saying that for e.g. minute 10:12, you're looking
at the High and Low of the 10:12 bar to determine the limit
orders in effect for that same 10:12 bar??
That seems very unstable. The H/L of your "virtual" 1min bar can
change continuously until the close of the bar. Do you expect
your limit order prices to change continuously throughout the
bar?
If so, then doing it on a 1tick chart is about the only way you
COULD do it. You'd be recalculating your limit orders on every
tick that made a new H or L within the bar. I'd be fairly
surprised if something like that really worked and was robust,
but I've been surprised before.
Usually (at least within the TS model) you use something stable,
like the H/L of a *completed* bar, to generate orders for the
NEXT bar, but maybe this moving-target approach works well.
> In my strategy settings, I noticed a "resolution" option which was
> un-checked. No idea what it does. I enabled it and selected "tick"
> resolution, thinking it would provide a cure for my problem. It
> froze up TS. I had to ctrl-alt-delete to terminate it.
Ordinarily TS uses the bars you see on the chart to calculate its
system behavior. That means it just uses the Open, High, Low,
and Close values of each bar.
Let's say you're trading with daily data, and you're running with
tight stops -- maybe a stoploss and profit target stops that both
fall within the range of one daily bar. Which stops got hit
first? Did the market hit your PT before it knocked you out for
a loss, or vice versa?
With just OHLC data you can't know. All you know is OHLC, not
what happened "inside" the bar. If you only have OHLC data (like
from an EOD data provider), you're stuck. TS makes some guesses
and assumptions to try to come up with a reasonable approximation
of reality, but it's a guess.
But let's say you actually have intraday data, and you build
daily bars using that intraday data. You actually have
information about what happened inside the bar. By default,
though, TS still just looks at the OHLC of each bar. If you turn
on the "increased resolution" feature, TS still executes the
system on the daily (or whatever) bar, just like it did before,
but it looks at the price action "inside" the bar to see what
stops would be hit first.
Obviously that can slow things down. A lot, in some cases. E.g.
if you run a system on daily bars, but tell it to execute stops
at tick resolution, you're doing a LOT more work. Chances are TS
didn't actually hang, but just hung up in a veerrry long
operation. But you don't need to check tick resolution on daily
bars. Tell it to look at 1min resolution, or 5min, and it will
run a lot faster. You could probably run 30 or 60min resolution
on daily bars and still be accurate, and a lot faster.
Bilo wrote:
> Gary is right. that's the major limitation in TS as a platform...
> all because TS is still a low res. platform. price path inside the
> bar is not known... however the truth is that they are just plain
> lazy, if they really wanted they could implemented it at least
> partially, ( without resorting to data1/data2 setup) for example in
> TS 6.0, 7.0 they could if they wanted use higher resolution like 1
> min or even tick to implement market/stop orders on current bar.
They *DID* implement that. That's the "resolution" option I
described above.
> ps. other major limitation that i am encountering now is overnight
> gaps which present discontinuities in the price, volume flow,
> especially in the markets with overnight sessions.
Yeah, that's a problem. It's especially bad if the market makes
a limit move. If price exceeds your stop level then TS blithely
fills you, whether you could actually have been filled or not.
Gary
|