Page 1 of 1

Consecutive ticks with same date/time = misplaced trades

Posted: Wed Sep 19, 2007 9:06 pm
by michal.kreslik
Hello,

with the internal fill, if the trade system happens to place a trade on a bar which is followed by bars with the same date and time as the one on which the trade was placed, such a trade does not get processed until there is a bar with a new date and time, no matter how many bars this might take in between.

I have discovered this today. I've recently imported Forex tick data into NeoTicker from HotSpot International. The data is high quality apart from the fact that it's only time stamped up to a one minute precision. Thus, all ticks "occur" at :00 (seconds) sharp.

This leads to me usually having many consecutive ticks (those that happened during the same minute) time stamped with exactly the same time stamp, like this:

20070724,084900,249.038
20070724,084900,249.039
20070724,084900,249.041
20070724,084900,249.044
20070724,084900,249.039
20070724,084900,249.033
20070724,084900,249.034

For the particular purpose this data serves, this time resolution granularity is fine for me. But Neo doesn't like consecutive bars with the same time stamp.

In this case, I'm using a 1-tick bar driven chart. Whenever I attempt to place a trade, it does not get placed on the immediately next bar (tick) as one would expect, but instead it gets placed on the nearest next bar with a new time stamp. This means that all bars in between are being ignored as if they have never been there.

To make my point, I've attached two screenshots from a simple trading system that I've written to illustrate the issue. The trading system places a random (either buy or sell) trade every 10th bar and closes the trade 5 bars later.

Have a look at the first picture:



This is a 1-minute chart, built from the tick data that only have the one-minute precision as stated above. You can see the red and blue dots in the indicator pane that mark the bars where the random trades were placed (blue dots) and where the exits were issued (red dots). Everything works fine here.

Now have a look at the second picture:



This is a 1-tick bar-driven chart from the same data. You can see that despite the fact that the trades are being placed and the exits are being issued in the correct bar intervals, nothing is happening until there's a bar (tick) with a new time stamp. The trades sort of wait in some "buffer" and then all of them are being processed at once and create a cluster on the bar with the new time stamp.

I hope there's some way on how to prevent this from happening.

Michal

Posted: Thu Sep 20, 2007 4:11 pm
by obx
Michal,

Did you consider transforming the test data by adding your own ?timestamp? to the time in an appropriate / importable format ?
The 084900 at 249.038 becomes 084901 or 08490001 or appropriate format
The 084900 at 249.039 becomes 084902 or 08490002, etc
Record 20070724,084900,249.038 becomes 20070724,08490001,249.038
Record 20070724,084900,249.039 becomes 20070724,08490002,249.039

pseudocode to transform data-

subMinute = .01 // or .0001 or correct Starting increment

do while not eof // read file line by line
thisRecord = ?read in this line?
thisMinute = mid(thisRecord, 10, 6) // timeportionOfRecord (084900 in this data)
If thisMinute = prevMinute then
subMinute = cstr(val(subMinute) + .01) // (or .0001, ie correct Increment)

else // thisMinute <> prevMinute
subMinute = .01 // or 00 or .0001 ie reset correct Starting increment

// end if thisMinute = prevMinute

insertMinute = mid(thisRecord, 10, 4) & subMinute
transformedRecord = mid(thisRecord, 1, 9) & insertMinute & mid(thisRecord, 16)

appendLine(transformedRecord) to new file

prevMinute = thisMinute

movenext // record

loop // while not eof

closefile, etc

hth