PureBytes Links
Trading Reference Links
|
Igor Uhrik wrote:
> I gather your comments are directed at Omega technicians.
> After all, it was they who deleted the INTC data from the
> January 5 Nasdaq tick file, claiming -- quoting from their
> ftp site -- that "the entires day's data for INTC is
> bad."
>
> Imagine, eight years in business, and they still do not
> know how to remove a bad tick... That'll teach them, and
> us, too.
>
> Or, you got it wrong. Next time, before you switch into a
> pompous mode, please check the facts first -- in this case,
> the actual original INTC Jan 4 intraday tick file. It can
> not be corrected by simply correcting the first bad tick and
> reloading. Ask Rod. He tried it before he sent me the file
> for correction.
The first two definitions of "pompous" in Webster's unabridged dictionary
are "splendid" and "magnificent," so I will consider that a compliment.
J. Rodney Grisham wrote:
> I don't remember questioning the correctness of any of your
> many previous posts. I think you are wrong this ONE time.
> If you've got the magic trick, please, let's hear it. Post
> it to the list. All stock traders will love you for it
> (figuratively speaking) :-)
My comments were that the method used save data in the Omega Server greatly
decreases the database file size and that it is only necessary to correct an
erroneous first price in a block to correct erroneous prices caused by it
afterward. I didn't comment on specific errors in any particular file. My
comments were about the advantage of the method and how the one problem it
can cause can be easily corrected.
I didn't have the INTC file until Rodney sent it. I have examined it since.
There is much more wrong with it than an initial wrong price, which was the
condition I was addressing. Omega could not reasonably provide software
that would automatically fix such a complexity of errors, at least not with
a high level of confidence that assumptions that would have to be made would
be correct.
Bad ticks are rare on our datafeed, but they occasionally occur. It is
extremely rare that they happen at the beginning of a file. It has happened
only a few times in several years collecting data for a large number of
symbols. However, in each case where it has happened, correcting the
initial price in a block has fixed all the wrong prices due to it afterward.
Both from knowing how the Omega Server saves data and from practical
experience with the system over a long period of time, I am quite sure the
statements in my post are accurate. However, I didn't say, and didn't mean
to suggest, that saved data cannot be badly corrupted by a series of
datastream errors, which is the apparent reason the INTC file is so badly
corrupted.
I don't think criticism of Omega's storage method is warranted, because I
think the greatly reduced database file size is vastly more important than
the few problems I have experienced because of it. In fact, I was so
impressed with the method, that I modified my own software several years ago
to save data the same way. We have had no problems whatsoever due to that
change since.
-Bob Brickey
Scientific Approaches
sci@xxxxxxxxxx
|