|
PureBytes Links
Trading Reference Links
|
Tomasz,
You're right. Sorry, I missed that bit. Which means we agree upon
that.
But even to create charts of bars of larger # of ticks, or to
backtest on larger # of ticks, one would always need a *true* tick by
tick database. A 5 sec database could never replace that. *Unless*
when compressing, each 5 sec bit would contain information on how
many ticks it originally contained. When a choise for a certain # of
ticks is made, this information would be taken into calculation, so
that you get a process of de-compressing too. Only in this way you
could come close to a "true" tick database, without the problems it
would impose as you described earlier.
Maybe there are practical reasons why this would not work very well,
I don't know, I've only just discovered tick bars, so I can't say a
lot more about it, except that it seems logical to do it this
way.
For AB it's a long term thing and certainly not responding to
everybody's needs (in fact I'm not sure myself if I will stick to
tick bars forever, but I know many people do), but maybe it's
something for, say, v5.00+ ?
Give it some thought (if it makes sense to you).
Regards,
Ralph
--- In amibroker@xxxx, "Tomasz Janeczko" <amibroker@xxxx> wrote:
> Ralph,
>
> You missed one important thing:
> I wrote:
> "Frankly I am not big fan of backtesting on single tick data"
>
> SINGLE TICK data - not N-tick bars.
> ==========
>
> Tick bars are compressed as interval bars are and
> they provide similar smoothing therefore less "noise".
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "allm4m" <allm4m@xxxx>
> To: <amibroker@xxxx>
> Sent: Friday, October 04, 2002 10:03 AM
> Subject: [amibroker] Re: TJ: tick charts, historical data
>
>
> > Hello Tomasz,
> >
> > Thank you for elaborating on this matter. Gives us some more
insight
> > on the special nature of tick data. Thanks Sean for bringing it
up.
> >
> > One more thing about it:
> > Although I'm rather sceptical about backtesting and especially
> > optimizing in general, I don't quite see why backtesting on tick
data
> > would be less reliable than on interval data. Well, if you
(could)
> > optimize for an exact number of ticks in a bar, yes that would be
a
> > clear example of "curve fitting". But other than that I would say
> > that the boundaries (O,H,L,C) of any bar are always a bit
arbitrary:
> > if a bar had closed three seconds later (e.g. due to a slow
computer
> > clock), the bar would be different, but it would not make much
> > difference for the whole picture of trend and momentum.
> >
> > When using tick bars, the same thing happens (as you know): in an
> > equally *arbitrary* way, the beginning and ending of a bar are
> > determined. The only difference is that the criterium for
determining
> > is not the amount of time elapsed, but a particular # of bars
having
> > occurred. As soon as you have chosen your tick #, the noise is
taken
> > out. Only the "smoothing" is done in a different way, but it's
being
> > done just as much as in an interval chart.
> >
> > I'm not talking about bars with very low # of bars of course or
very
> > low liquidity stocks, then it may be a different matter. But
working
> > with say, 50, 100, 200 and 500 tick charts on liquid securities,
> > should not be less reliable in backtesting (or chart study) than
say,
> > 1, 5, 15 min bars charts.
> > At least I fail to see why it could be.
> >
> > So for the near future, I'm happy with your promise of raising
the
> > 100000 bar limit. On a longer time frame you might consider a way
> > for "true" tick importing from ASCII. Despite huge file sizes and
> > resource problems, I think it would be appreciated by more people.
> >
> > Regards,
> >
> > Ralph
> >
> >
> >
> >
> >
> > --- In amibroker@xxxx, "Tomasz Janeczko" <amibroker@xxxx> wrote:
> > > Hello,
> > >
> > > > I have the realtime version but not with a eSignal feed. With
> > eSignal
> > > > can you request historical tick data from their servers? If
so,
> > how
> > > > much can you load into AB?
> > > >
> > > Yes eSignal plugin provides tick histories. There is a limit of
10
> > days
> > > of tick data and 100000 bars currently. The 10 days limit is
imposed
> > > by eSignal tick server, 100000 bars limit is imposed by
Database
> > settings
> > > window in AmiBroker. Since I have been asked to increase it
> > > - I will do that in the next beta.
> > >
> > >
> > > > Given the ascii import limitation how is a person supposed to
go
> > > > about realistically backtesting longer amounts of tick data,
> > > > especially if eSignal doesn't provide access to large amounts
of
> > > > historical tick data? For running the system, eSignal would
be
> > fine,
> > > > but unless you can request severals months or longer worth of
> > tick
> > > > data from eSignal how could you possibly back test?
> > >
> > > As written above eSignal provides max. 10 days of tick-by-tick
data.
> > > Frankly I am not big fan of backtesting on single tick data.
> > > There are several reasons for this:
> > > a) tick data for one day can be 1MB or more. Several months
> > > of tick data will sum up to more than 100MB of data. This
> > > will slow down backtesting very much.
> > > b) there is much less probability that system backtested on tick
> > > data will ever work in reality. This is due to the fact that
tick
> > data
> > > represent much more "noise" than interval data that represent
some
> > kind
> > > of "smoothed" market response. Backtesting and optimization
> > > systems on tick data is much more prone to curve-fitting and
over-
> > optimization.
> > > Also backtesting system on tick data is bad idea because
> > > it gives you false feeling that you can trade on every tick.
> > > In reality we have to face slippage, order routing delays and
other
> > problems
> > > that make backtesting on single tick data much less reliable
> > > than testing interval data.
> > >
> > > >
> > > > I also don't understand why their is a difference between the
way
> > > > ascii importer works and the eSignal plugin. Is the eSignal
data
> > > > compressed in the same way as the ascii importer data or not?
> > > No.
> > > The difference comes from the fact that plugin architecture is
> > completely
> > > different from what ASCII importer does.
> > > Plugin cares about the data and provides ready-to-use
> > > quote array to AmiBroker.
> > > AmiBroker just uses it without any transformation.
> > >
> > > ASCII importer is quite different - it reads the input file
line by
> > line
> > > and matches date and time values read to records already
present in
> > the AmiBroker
> > > database - if a matching record (for the same date/time) is
found
> > > new data overwrite existing record and no new record is added.
> > >
> > > Now consider tick data. Tick data very often contain multiple
> > records
> > > for the same hour:minute:second. No data feed provides more
> > resolution
> > > than ONE second so multiple trade records occur for the same
second.
> > > With plugin architecture - such records are passed directly to
> > AmiBroker
> > > and it accepts multiple records with the same date/time.
> > >
> > > Using ASCII importer - you can not import multiple records for
the
> > same
> > > symbol, date and time because once data because matching record
> > > overwrites existing one so if you try to import 5 records
having
> > the same time
> > > one will overwrite another and only one (the last one) will
remain.
> > >
> > > This behaviour is required by 99.9% users because people want
> > > to re-import their data (with probable data fixes) and want new
> > data to
> > > overwrite old data.
> > > Also ASCII importer does not imply any ordering of data thanks
> > > to this matching mechanism. You can import year 2001 then 1998
then
> > > 2002 then 1999 and everything will work OK.
> > >
> > > Allowing multiple records per same date/time will force you to
> > > "assume" some rule to distinguish and order such records.
> > > You would need to assume that new record is newer or older than
> > > the previous one with the same date/time.
> > >
> > > Now with eSignal plugin this is not a problem because
> > > eSignal builds up entire quote array - it is aware of multiple
> > > records per same second and nows about the correct order since
> > > eSignal servers return tick histories in correct order.
> > >
> > > >
> > > > I understand that you don't officially support tick data
charting
> > > > without the eSignal plugin, but please appreciate that I am
> > > > attempting to backtest here. I really am not currently
concerned
> > with
> > > > realtime tick charting. When I get to the point of running my
> > > > systems, then maybe, but not now. I also understand that you
only
> > > > have so much time and that you can't go supporting every
crazy
> > > > project of every person that buys your software. I am ALL FOR
> > going
> > > > about this myself, but please appreciate the fact that there
is
> > > > nothing at all in the help files about tick charting or the 5
> > second
> > > > issue with ascii import.
> > > I agree that I didn't write that exactly but I did write that
> > > only RT version supports tick, 5-sec, 15-sec and I did write
that
> > > you need eSignal subscription.
> > >
> > > I will be publishing data feed plugin API soon with a sample
> > > code and I will think about adding a section how to implement
> > > plugin that reads ASCII tick data.
> > >
> > > As I explained above - the special nature of tick data
(multiple
> > records
> > > for the same second) - make it different story to import it
from
> > ASCII file
> > >
> > > Best regards,
> > > Tomasz Janeczko
> > > amibroker.com
> >
> >
> >
> > Post AmiQuote-related messages ONLY to: amiquote@xxxx
> > (Web page: http://groups.yahoo.com/group/amiquote/messages/)
> >
> > Check group FAQ at:
http://groups.yahoo.com/group/amibroker/files/groupfaq.html
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
|