honvly

The code isn't ready to be shared, as the indicator values still seem inaccurate when compared to UrmaBlume's original. There are still too many failures to reverse, good trades below the absolute threshold, etc.

I have noticed this behavior, and it is immensely confusing. Bid intensity at bottoms results in upward swings in price, and vice versa. However, it may be possible to use this behavior to filter out stop market orders, which one would expect to trade at the ask as price moves lower.

UrmaBlume, Thanks for the theory and the screenshots. I compared it to screenshots of my own for that day, and it is clearly apparent that I have much work left to do in order to achieve the numerical accuracy that you have.

I was looking at absolute values >1100 yesterday. The automated trades were based on intensity filtered by high values on the unnamed indicator below that. The trade on the right edge was taken because the red intensity went above 1100.

Some trade intensity based trades taken today:

Here is some order size and market impact data that may be useful for tweaking the volume filters of the trade intensity indicator. EQ221OrderAnalysis0309.pdf

Sorry, I have not gained any further insights on trade intensity from concentrating on market structure. If you would like, please explain further.

Successful sim trade today using a trade intensity strategy

This is a concept with a lot of edge, though perhaps more so for detecting major pivot points than for high frequency scalping.

I've finished developing the indicator. As UrmaBlume said, there are issues with the way NinjaTrader handles Zen-Fire data. Particularly, NinjaTrader takes the Zen-Fire tick timestamps, which have microsecond precision, and reprocesses them in such a way that it ends up with second precision. But even if you can't get the real timestamps, you can record the time at which your computer receives the tick and hope that is accurate enough. Through watching this indicator, I've figured out that the spikes in trade intensity represent the instantaneous distribution of contracts that extremely large traders have accumulated over a trend. They are dumping all of their contracts in the most liquid direction. That is why only some spikes lead to a reversal in the trend, while others seemingly have no effect on the ongoing trend. This makes the indicator a little hard to work with as it is not a sure-fire signal of reversal.

Thanks for the great information. Can you go into details about how Ninja handles this data stream making it unsuitable?

No need for programming. Use the built-in TickCounter indicator on a 1 second chart.

UrmaBlume, How do you define trader commitment? What are the issues that you have discovered with traditional bid/ask volume or uptick/downtick volume? Thanks.

My time unit is the millisecond. For example, if a trade arrives in 100ms from the last trade, I will take the volume and divide it by ln(100) = 4.6. That way, trades that arrive slowly do not contribute as much to the intensity, but at the same time they are not completely discarded.

I am using new logic to reduce the impact of time. For trades that arrive in less than e = 2.71828183 ms since the last trade, I use the tick volume itself as the intensity. For trades that take more than e = 2.71828183 ms, I divide the tick volume by the natural logarithm of the duration in ms and use this value as the intensity. However, I am still not sure whether I should average the intensities over each tick in the bar or simply add them up.

I am using the TimeSpan class's TotalMilliseconds method with the difference in DateTime.Now and changed my volume capture code from OnBarUpdate to OnMarketData. This has changed the 3-7ms differences to 0-1ms. However my current formula does not accurately capture the first trade in a flurry, since it has a large time difference from the previous trade, and it also does not capture the 0ms trades, since I am dividing by duration in my formula. I need to write more code to take care of these cases. Here's some sample output. difference(ms)---trade size 241----23 0----103 1---29 0---10 63----29 710.0516----10 5310.1485---10 0---32 37---13 1----97 4677.2----267 1---14 0---13

I am using Zen-Fire. Right now I am just dividing the contract size by the 3-7 ms differences and averaging this value across all ticks in a bar. However, I believe that the 3-7 ms differences are artifacts of NinjaTrader's bar processing speed. To improve the accuracy, I am going to try to increase the millisecond differences by filtering out trades less than 10 contracts and splitting bid/ask volume.

Me too, I whipped one up using AgeKay's formula and averaged the trade intensities over the bar. Here are the millisecond differences of a bunch of ticks. I assume the ones with 3-7 ms differences are trades that happen one after another. 3.0003 0 3.0003 3.0003 49.0049 3.0003 3.0003 3.0003 3.0003 2.0002 7.0007 3.0003 3.0003 3.0003 6.0006 3.0003 4.0004 3.0003 3.0003 3.0003 5.0005 3.0003 5.0005 3.0003 6.0006 3.0003 0 48.0048 2.0002 95.0095 3.0003 4.0004 3.0003 3.0003 3.0003 3.0003 3.0003 3.0003 44.0044 128.0121

UrmaBlume, The timer resolution of Windows machines is about 16 milliseconds. The jitter of the packets in an internet connection is at least 10-20 milliseconds. How do you deal with or avoid issues coming from the millisecond frequency?