|
PureBytes Links
Trading Reference Links
|
I thought somebody might benefit by this observation:
>Then there is another category of bad ticks -- the ones that are off
>by a big margin. For some eerie reason, TS stores each tick that
>is off by more than about 33 points -- 330 points for high priced
>symbols -- at a value that is different from the original value. (I think
>the threshold is closer to 32.817 -- or 328.17, as the case may be
>-- but I do not have time to figure that out....
The number 32767 is a "magic" number in computers. Whenever I see weird behaviour
around this level, I immediately suspect it has to do with the storage of
integers.
If a programmer is saving a 16 bit integer, he can decide whether those 16 bits should
represent the numbers 0 to 65535 (unsigned integer), or -32768 to 32767 (signed integer).
If you ever notice behaviour as numbers cross above the 32767 mark where they suddenly turn negative or start to act odd, then that number is likely stored as a "signed" integer. Often it should have been stored as an unsigned integer. Frequently this happens when the programmer never anticipated the numbers getting bigger than 32767.
For instance, for those of you with block ID's over 32767, go into your Help About menu, and check on your block ID. It'll be reported as a negative number! Add 32767 to it to get your real block ID! (Don't worry about it - it won't affect any of your systems.)
When data is being stored, there's often a scaling factor of 100 or 1000 applied so that the magic number is changed to 32.767 or 327.67. I'm pretty sure this effect is at work
on these bad ticks that IUhrik has been discussing.
None of what I'm saying here helps solve the problem, but it might help de-mystify aspects of it.
Mike Gossland
|