|
PureBytes Links
Trading Reference Links
|
> i was told not to change the price scale but to edit the first bad
> tick with the same value as the last good tick(continuing so until
> no bad tick existed), all this while in the edit tick screen, i
> used a 0.5% filter. today the problem resurfaced again.
Unless I am seriously mistaken, the Omega support person was confused.
The problem he describes happens if you get a bad tick at the start
of a block of 64 (? not sure about that number) ticks. All the ticks
in that block are offset from the first tick in the block. If the
first tick of the block is bad, all ticks in the block are bad.
The symptom of that problem is that a block of 64 (or whatever)
continuous ticks are wrong, then the price reverts back to the right
price. It doesn't depend on the price, just on a fixed # of ticks
after an initial bad tick that falls at the start of the block.
After 64 ticks, the price reverts back to the proper range.
That's not what we've been seeing lately. For one, you often see the
price jump 655-odd points AND BACK, several times, within a few
ticks. Also, the jumps happen precisely when the price passes 327+
pts from the opening tick, and the jumps are exactly 655.36 high or
low from where they should be. That doesn't fit with the "bad tick
at the start of a block" problem, but it DOES fit the "16-bit offset
from the open" problem. Finally, changing the PriceScale DOES FIX
this problem. I changed my PriceScale and my data for yesterday
stored properly.
By the way, for some reason the OMZ files I posted are not working
properly. When *I* download them, I see all the symbols I expect.
But several people have said they see only @CCO and NDX, or only ND0M
and NDX. I can't explain what's going wrong there. The OMZ file
works properly on my system.
Gary
|