|
PureBytes Links
Trading Reference Links
|
The issue of the chart re-adjusting the bar or signal
takes place when a price gaps, not because of tick
time sequence.
If your active order was a buy at 101.10, and trades
took place at 101.01, .02, .03, .04, .05, .06, .07,
.08, then traded at 101.12, the signal would be placed
at 101.12 (the traded price) so long as you did
nothing to refresh the chart data. If you refresh the
chart data, then the signal would move to 101.10 (the
active order). Therefore when doing historic
evaluations and or optimizations for strategies,
erroneous results are present.
In 2000i, the order in which the ticks come in are not
used in the making of the bar. The only time it is
meaningful is on a 1 tick.
Omega uses "bouncing ticks" (which is adjustable and
silly in my opinion) with Omega developed assumptions.
I know this because I was one of the Beta testers and
had many conversations with Omega Staff including Bill
Cruz. This is one issue of many that I pushed on very
hard (having bought 14 4.0 packages and submitted many
unknown bugs to them for years on a number of products
bought me a tiny bit of clout)for change. It took a
lot of pushing and in the end they added a
non-functional feature in the optimization section. My
last towel thrown in, I began to try and work around
issues rather than point them out to them.
Because my use of 4.0 goes back many years, I don't
remember how they handled the data bar issue.
Thanks
Don
--- Bob Fulks <bfulks@xxxxxxxxxxxx> wrote:
> You need to understand the source of these kind of
> problems.
>
> All platforms respond to each tick as they arrive.
> If a tick arrive that causes your system to trade,
> it will issue the orders. If the tick happens to
> have a time stamp out of order, it may be stored in
> the server data base in a different place or not
> stored at all, depending on how the system is
> designed.
>
> TS4.0 uses time stamps as provided by the vendor.
> These can be exchange time stamps or the time the
> vendor's server sent the data. It depends upon the
> vendor. These can be and frequently are out of
> order. I don't remember how they are stored on the
> TS4 server.
>
> TS2000i, as I recall, used your computer's time that
> the tick arrived as the time stamp to help eliminate
> this problem. This keeps the time stamps in order
> but the time stamps can be off if your computer time
> is not correct. And if you download refresh data the
> time stamps on that data will be the exchange time
> stamps or vendor time stamps so will be different.
>
> This explains most of the differences you will see.
> But if you have more than one entry/exit on a bar (a
> very bad idea), you then get into the subject of how
> TradeStation assumes the ticks arrived when it only
> has OHLC data on each bar.
>
> Bob Fulks
>
>
>
>
> At 07:56 PM 9/9/2005, Donald Beck wrote:
>
> >I am planning to setup my trading for Forex and
> >therefore my ability to feed the server data is my
> >first concern. I am planning to use Hyperserver,
> >Metaserver or Dynaloader either in a plain wrap DDE
> or
> >a platform specific package. These will take the FX
> >data from the broker I will trade with.
> >
> >As important as the data feeding issue is, so are
> the
> >changes in the value of the bars be it in tick or
> >minute data. My strategy will fire signals during
> the
> >formation of the bar (as opposed to on the close of
> >the bar). I have found in 2000i a signal can have
> you
> >buy at lets say 101.30 and sell at 102.40. Upon the
> >closing of the chart, the signal may remain at that
> >price or the buy may move to 101.20 and the sell
> >102.50 (as example). Still more rare would be the
> >addition of, change of or elimination of bars and
> >therefore the same would be true of signals.
> >
> >These findings are not new to me however it may
> impact
> >the viability of my Forex trading plan. This is why
> I
> >am trying to explore 4.0, to see if it is a viable
> >alternative.
>
>
>
|