TRANSLATION FROM JAVA TO C#

I've always heard that the C# core language was a
"rip off of Java" but, in fairness, I think they inherit
from the C language as part of the explanation; but
also the standard C# (Microsoft .Net) Library functions
are remarkably similar... Hmmm wonder how that
happened? LOL Java was my first love, and you
know how that goes... ha ha

Nevertheless, and fortunately, that makes it fairly
easy to translate code from Java to C#.

My legacy Java UnifiedInventory module is about 1,000 lines of
code; and I was able to translate it fairly easily into C#
so..... That sets the stage for a more comprehensive
Inventory Analysis which I won't promise to deliver,
but which might be a deliverable down the road.

It's a lot of computing for a NinjaScript Indicator
with everything in a single file... So I'll have to do
some thinking about whether or not it's worth the
trouble to have to shoe-horn it into that format. Sorry.

THE PROBLEM WITH NINJASCRIPT INDICATORS, as you
may know, is that if you mess with them, changing
parameters, then you force a Terminate and are forced
to restart all of the RealTime processing... That's no
good when you're trying to hold several Hours worth
of Trade Price/Volume Time and Sales data in memory
in order to extract InventoryResults for specific Analysis
Timeframes.... LOL

That's why I did this simple TradeFlowAnalyzer Indicator
using the file-based Properties, which could be changed
on the fly, without having a reset of the Indicator...
Not everybody likes the idea of RealTime processing
only, I discovered. But I just don't do historical replay,
since I'm usually not measuring things that exist in
a Backtesting environment anyway...

There would be outcries from everyone that it needs
to be able to populate from the historical replay; and
I'd complain about accuracy and all the little details
that requires and, in the end, it wouldn't be appealing
to me to do all of that work just to get it into a
NinjaScript Indicator container.... (frowny face
from everybody)

So, firstly, I'll try to embed it in my own C# system
and shake out any bugs. Then I'll consider whether
it's worth it to deliver a Full Inventory Analysis Indicator
standalone, for NinjaScript 8...

Don't be a Hater, if i finally decide it just isn't worth it.
Because, as I stated above, the results are broadly
similar, even though much more information is provided
by what I'll call more comprehensive Inventory Analysis.

[edit] What does a more Full Inventory Analysis yield?

1) We know that Market Maker always "makes the spread"
and we as Retail players generally (not always) "pay the
spread". A Full Analysis will tell you, for the Time Period
how much actual Money the MM is making "per minute"
by "Spread-like Profits". So let's say they're running
at $1000 / minute profits; then if they have $1000 of
Risk, you can see that they're actually fine; breaking
even on Revenue vs Risk. They are really "pocketing"
a sometimes "obscene" amount of money, simply by
virtual of Being the Market Maker (understood in aggregate).

2) Multiple Timeframe Analysis tells you, for a range of
Analysis periods, what the situation is; so that you can
more easily understand the "cycles" of the market,
and maybe "match" your own Trading hold intervals,
to those of the Market as it's actually trading. Just sayin'

Having this perspective, that at Tops and Bottoms, simply
the Volume of Trading ("the Battle between Buyers and
Sellers") reaches such a Frenzy, that MM has a "profit
run rate" which spikes; so no wonder they are lingering
there; as that spike in sheer volume is money in their
pocket(s)... And also the fact that they may "run through"
a Support or Resistance level; even though they are apparently
losing money on Risk; because of all the profits they have
already accumulated, etc.... It's an awesome thing
to be Market Maker. ha ha

hyperscalper

TradeFlowAnalyzer Indicator.... is that the TradeFlow software they want 200/month for.....

loantelligence 

TradeFlowAnalyzer Indicator.... is that the TradeFlow software they want 200/month for.....

Oops, I guess we called this one TradeFlowRisk; but I'm sure it's
also worth $200 / month to the right Trader... LOL

h.

To get the VWAP when Net Inventory is "MM Short", as you pointed out,
we use NOT ALL VOLUMES, but selectively choose only the Retail Buy
volumes, when we form the Volume Weighted Average Price, representing
the "Price of MM's Short Inventory".
Same, but reverse logic, applies when Net Inventory is "MM Long".
Only the Retail Sell volumes are used, whose associated Prices form
the VWAP.
situation.

I copied this from "TradeFlowRisk" and I'm hoping these lines of code were
what you were describing..

if (calcMethod!=VWAP_ALL_VOLUMES) {
if (calcMethod==VWAP_POSITIVE_VOLUMES) {
if (volume<0) continue; // ignore NEGATIVE
}
else if (calcMethod==VWAP_NEGATIVE_VOLUMES) {
if (volume>0) continue; // ignore POSITIVE

May I ask for clarification on the method used to "choose only the Retail buy volumes" when
calculating the VWAP to use in representing the "Price of MM's Short Inventory" in the
first example?

I wanted to ask this as I've found at least a couple ways to "sign" volume.. One is to count
all volume below the open as positive in a given bar and vice versa.. and another I read was to
"Close[0] > Close[1] ? Volume[0] : Volume[0] * -1;" This case is kind of different in that its counting the volume in this bar as positive or making it negative based on whether the close is above close[1] or not. Your method(s) appear to be a better way. I'd like to use it if I can understand how it works. Oh btw I'm conceding that I probably don't have all the code pasted in here that is required to "choose only the Retail buy volumes" and calculate the VWAP we want to use.. and really the simplest explanation is more than appreciated.. For me you wouldn't have to explain the moving time window or how or where the "risk" is calculated/assigned.

If any of us learn a better way to calculate accumulation and distribution from your explanation, I think you'll be doing us a big favor..

thnx HS

Chuck

Chof 

To get the VWAP when Net Inventory is "MM Short", as you pointed out, we use NOT ALL VOLUMES, but selectively choose only the Retail Buy volumes, when we form the Volume Weighted Average Price, representing the "Price of MM's Short Inventory". Same, but reverse logic, applies when Net Inventory is "MM Long". Only the Retail Sell volumes are used, whose associated Prices form the VWAP. situation. I copied this from "TradeFlowRisk" and I'm hoping these lines of code were what you were describing.. if (calcMethod!=VWAP_ALL_VOLUMES) { if (calcMethod==VWAP_POSITIVE_VOLUMES) { if (volume<0) continue; // ignore NEGATIVE } else if (calcMethod==VWAP_NEGATIVE_VOLUMES) { if (volume>0) continue; // ignore POSITIVE May I ask for clarification on the method used to "choose only the Retail buy volumes" when calculating the VWAP to use in representing the "Price of MM's Short Inventory" in the first example? I wanted to ask this as I've found at least a couple ways to "sign" volume.. One is to count all volume below the open as positive in a given bar and vice versa.. and another I read was to "Close[0] > Close[1] ? Volume[0] : Volume[0] * -1;" This case is kind of different in that its counting the volume in this bar as positive or making it negative based on whether the close is above close[1] or not. Your method(s) appear to be a better way. I'd like to use it if I can understand how it works. Oh btw I'm conceding that I probably don't have all the code pasted in here that is required to "choose only the Retail buy volumes" and calculate the VWAP we want to use.. and really the simplest explanation is more than appreciated.. For me you wouldn't have to explain the moving time window or how or where the "risk" is calculated/assigned. If any of us learn a better way to calculate accumulation and distribution from your explanation, I think you'll be doing us a big favor.. thnx HS Chuck

Hi Chuck,

Good question.

We're not using any "bar" concept here. We use the "instantaneous"
Bid and Ask price, which is conveniently delivered along with the
OnMarketData callback, when a Trade is reported; as the basis for
categorizing the trade as a Retail Buy or a Retail Sell, using the "Last"
event.

The idea that this might in a small proportion of cases, miscategorize
an individual trade; would have little effect on the outcome with many
hundreds of trades, etc.

Yes, we know that some Retail traders; like myself, use Limit orders
to "Buy the Bid" or "Sell the Ask"; but the majority of transactions
will involve Retail players using Market Orders, so they will Buy the
Ask, and Sell the Bid. This is part of the definition of "retail".

Unless you have software, as I do, which is able to manipulate Limit
Orders, then your easiest action is just to use Market Orders; so that
doesn't affect the ability to determine Market Maker versus Retail.

Many traders think they can "trade by the tape". Well, good luck, but
I'd say only a computer process can properly evaluate Net Inventory
Balance. The question then is, even IF you can capture the data, and
process it; what are you going to do with that information ??

That involves having a Theory, according to which you develop
predictions when certain conditions exist; otherwise it doesn't much
help your Trading decisions, of course.

(My code might not be as "clean" as it should be; with an "as is" status)

[EDIT] I'm thinking I didn't specifically answer your question... So the
reason for choosing the "Retail Buy Transactions" or (up volumes,
positively signed) is that there is a "flurry" of "late Retail Buyers" near
a Top, and so what we are detecting here is really the disproportionate
number of Retail Buyers (who are Buying "at the wrong time") near
a Top. What actually happens, as a way of justifying this simplification
of the algorithm, is that Market Maker intentionally pushes the Price up
at an accelerated rate; which causes Retail players a form of "FOMO"
(Fear of Missing Out) with regard to a possible rally; and so they Buy;
and that is *exactly* what MM intends the Retail aggregate population
to do; so that MM gets the Highest possible "MM short" VWAP pricing
against the Retail Population. At that time, the MM is "losing money"
since the actual Market Price is HIGHER than her cost of Inventory (VWAP).
Naturally, after capturing these sad Retail players who have bought too
high, Market Maker then quickly Reverses the Price; so these
unfortunately "late Retail Buyers" will suddenly realize the mistake
they made... etc. This is how Trading operates on a Short Term basis,
and is responsible for the "sawtooth" behavior of short term micro
trending, etc...

So this is a dynamic which is fundamental
to trading; and this simplified algorithm nicely picks up on that behavior.
Yes, not ALL Retail players are Buying; but a large proportion. Of course,
SOME Retail players are trying to Sell the Top; but these things happen
quickly; and the dominance of the Retail Buy events will "pull" the VWAP
slightly higher (as opposed to using an unsigned vollume) but the Market
Price will accelerate higher much faster; and it's ABOVE the VWAP on
"MM Short Inventory"; causing the Risk situation to exist, as we are
estimating in this Indicator.

The reason for choosing ONLY the Positive volumes here; is that their VWAP
(due to higher frequency, and higher trade lot size) will be Higher than
a VWAP formed from Negative volumes, or ALL volumes; so we then
have a Higher estimate of the up-move's VWAP; and so any Market Pricing
higher than that value; represents what I'm calling "MM Short Risk".
There will be a differential between using only Positive Volumes, versus
using Negative Volumes or All Volumes in the formation of the VWAP.
Our choice of Positive volumes only, forms a Higher VWAP, above which
we are more certain that MM is in "MM Short Risk". It's a simplification
of a true full Inventory Analysis; but it easily captures the situation which,
in practice, looks pretty good most of the time in identifying relative
Tops and Bottoms (with reasonable Parameter settings, of course)

[EDIT2] One more thing: ONLY when Net Inventory imbalance is "Short" can
we have "MM Short Risk"; and only when it is "Long" can we have "Long MM Risk".
You may have noticed that in observing the Indicator in operation. We are
always looking at things from Market Maker's Inventory perspective.

hyperscalper

UPDATE SCREENSHOT OF PERFORMANCE WITH NASDAQ

The Nasdaq is BRUTAL in its swings; and here you see a
50 Point swing, which is fairly effective at marking tops
and bottoms; but...

Of course, as I've said before, this is a "situational awareness"
and so it should factor into your expectations as to where
a Trend Turn is on the cards...

hyperscalper

Hi HS,

No, really I had your general trading/scalping concept from the thread. This really
makes it clear tho'. It also draws attention to the bits of code that clearly label the
risk as ''short risk'' in an extended long rally where the MM would be ''losing money''
but continues to snap up overextended longs and vice versa.

If I can also add, it also really makes it clear that (in particular) the NQ rarely turns on a
dime.. the 5 pt. "punches" are mostly the MM taking multiple short term wins at the
expense of ill timed retail longs before the drop where She really cashes in.. Personally,
when I finally found that I had to follow multiple markets and currencies (in some cases)
to really see a market turn my win rate went way up.. but that's for another thread.

My goal is kind of selfish in that I'd like to use the ".get volume" concepts in my code instead
of using the bar related volumes. I'm thinking the "tapering" utility in your code masks the
underlying methods to someone that hasn't mastered C# the way you have. And/or
doesn't have the computer science background. This tends to make using the method
invisible..

To be more specific - how can I use Onmarketdata callback volumes instead of bar volume?
say, in a line of code like this:
R[0] = Close[0] > Close[1] ? Volume[0] : Volume[0] * -1;
VP = EMA(R, Period)[0];
TV = EMA(Volume, Period)[0];

rather than concepts, think of this post as a request for a class called "using tape data 101"
(I'd more than understand if this is too big an ask)

Chof 

Hi HS, No, really I had your general trading/scalping concept from the thread. This really makes it clear tho'. It also draws attention to the bits of code that clearly label the risk as ''short risk'' in an extended long rally where the MM would be ''losing money'' but continues to snap up overextended longs and vice versa. If I can also add, it also really makes it clear that (in particular) the NQ rarely turns on a dime.. the 5 pt. "punches" are mostly the MM taking multiple short term wins at the expense of ill timed retail longs before the drop where She really cashes in.. Personally, when I finally found that I had to follow multiple markets and currencies (in some cases) to really see a market turn my win rate went way up.. but that's for another thread. My goal is kind of selfish in that I'd like to use the ".get volume" concepts in my code instead of using the bar related volumes. I'm thinking the "tapering" utility in your code masks the underlying methods to someone that hasn't mastered C# the way you have. And/or doesn't have the computer science background. This tends to make using the method invisible.. To be more specific - how can I use Onmarketdata callback volumes instead of bar volume? say, in a line of code like this: R[0] = Close[0] > Close[1] ? Volume[0] : Volume[0] * -1; VP = EMA(R, Period)[0]; TV = EMA(Volume, Period)[0]; rather than concepts, think of this post as a request for a class called "using tape data 101" (I'd more than understand if this is too big an ask)

Hey, I'm glad you're thinking about all this; since that was mainly
the whole point of this thread...

Firstly, yes, the Nasdaq futures (NQ/MNQ) uses a wide ranging
approach toward "total destruction" of short term retail traders
like us. So if you're holding 1 or a collection of eMini NQ's then
you are at High Risk of being slapped; if you're making the wrong
decision, especially anywhere inside the first half hour of the Open.

Being able to tolerate (significant) Price Adversity is essential
to survival in the Nasdaq futures market; and Market Maker
makes that level of consistency, virtually impossible in short term trading...

So, being "predatory" is a Key to success; and being able to use
multiple individual contracts at varying prices, and using the Micro
MNQ contract; can be essential to "survival and thrival". Personally,
I call this "micro nibbling" but without some semi-automated support
to manage 10x the number of contracts, it's gonna be just about
impossible.

But, on a smaller scale, you can certainly widely space MNQ contracts
and can tolerate the "brutal price adversity" which Nasdaq can
throw at you; then that certainly helps a lot !!!

NOW ON TO SOME CODE TECHNIQUES

Most traders are operating on concepts of a "bar or candle" where
there is OHLC (Open, High, Low, Close) as the only data points
available; but in order to do Trade Flow Risk type analysis, you
must use "instantaneous" pricing.

That means in OnMarketData, in NinjaTrader 8, you will use the
a declaration like this:

 

Code

protected sealed override void OnMarketData(MarketDataEventArgs dataPacket) { // to be Trader Coding friendly... NT guarantees NOT ever to // use re-entrancy here; so only a single thread will call here // and you never have to worry that a second execution Thread // might call here WHILE the first thread is in the middle of calculations... // this is known as "serialization" of executions // just sayin' that most coders might not realize this convenience // makes coding simpler. HOWEVER, keep all calculations at the // bare minimum; since NT cannot call again for another trade // until this routine RETURNs... always think about the very fast // sequences of events which the market can generate; e.g. at the Open // .... but most coders do not have to be aware of this; just be efficient // feel free to delete these comments // MarketDataType type = dataPacket.MarketDataType; // what type is this callback? if ( type == MarketDataType.Last) { // this is a Time and Sales Trade event // and this event is guaranteed to carry with it, the Bid and Ask price // at the time the Trade was executed, which is nice double tradePrice = dataPacket.Price; // price at which Trade occurred double bidPrice = dataPacket.Bid; // Bid price at the time of the Trade double askPrice = dataPacket.Ask; // Ask or Offer price at time of Trade // assuming here that askPrice is always >= bidPrice... double midPrice = 0.5 * ( bidPrice + askPrice ); // halfway between // now that we have a midPrice; one way to categorize is simply // to see whether the Trade Price is above or below it // a Trade can be executed BETWEEN the Bid and the Ask price int tradeLotSize = (int)dataPacket.Volume; // integer # contracts in the Trade if ( tradePrice < midPrice ) { // this is a Retail Sell Trade to Bid, or Market Maker Buy // retail sell processing (MM is Buying from a Seller) // we use -tradeLotSize to represent that } else { // retail Buy processing // retail buy processing (MM is Selling to a Buyer) // we use positive +tradeLotSize to represent that } } else { // other types of callback information } }

There can definitely be dozens or even hundreds of such individual Trades
inside a Bar or Candle, obviously depending upon the Chart bar settings.

However you are doing your "inter-bar" processing, you will then "snapshot"
your calculations when OnBarUpdate happens; and then typically place
things on your Chart using this custom indicator representing the calculations
which you are doing ON EVERY SINGLE TRADE, obviously.

It's NOT usually desirable to use OnBarUpdate OnEachTick; and you SHOULD
probably be using OnBarClose instead, so that you do not have Multiple "snapshot"
OnBarUpdate calculations INSIDE a single individual bar;
which you probably don't need in order to represent things on your Plots.
However, it's all up to you !!!

[EDIT] YOU MUST REALIZE HOW FAST THINGS HAPPEN !!! NinjaTrader
is just about the FASTEST platform, and for OnMarketData is will be
calling your code for 1) each trade, and even worse, 2) for every
change in the Bid price, and 3) also every change in the Ask price !!!
Just imagine how fast that will be; depending upon the Quality of your
Market Data feed. This is VERY fast. And if you were analyzing the
Market Depth using OnMarketDepth (which I do...) then you are
looking at callback Events happening as high as 1000 EVENTS PER SECOND.
Time and Sales, OnMarketData usually generates slower updates than
that; but BE AWARE that every calculation you do inside the OnMarketData
routine MUST be as Quick as possible; so that you can Return and allow
NinjaTrader to call you AGAIN as soon as possible !!!!!!

[EDIT2] I am NOT recommending you do this, since OnMarketData
callbacks are not generally insanely fast. But I use the Rithmic data
feed, and for OnMarketDepth events, like I said, I will get "burst
data rates" in the range of 1000 events per second... So I use a
"queue capture, and process" approach; where I capture the data
I need, queue it, and then immediately RETURN from OnMarketDepth.
That queued data is processed as quickly as possible in a
DIFFERENT High Priority Thread of execution. Extreme measures
like this may be required, in order to make sure no data is ever
skipped due to exceeding C# ability to process. There are times
when the Queue processor will need to DISCARD some data in
order to "keep up" especially with Market Depth data with 60 Tiers
above, and also below, the Market... Just sayin'...

[EDIT3] Many of you will want your code to process in the Historical
phase of loading; and then of course the Realtime phase. Historical
and especially Backtesting Playback will NOT be as accurate as the
Realtime situation. In fact, NinjaTrader documentation discusses
that you may have to do special coding, generating what they call a
Bid Ask Series in order for the categorization of Buys/Sells to be
more accurate... This, I've never done, so it's up to you to read
about that in NinjaTrader documentation... Here's a starting point:
https://ninjatrader.com/support/helpGuides/nt8/NT%20HelpGuide%20English.html?using_historical_bid_ask_serie.htm
especially here:
https://ninjatrader.com/support/helpGuides/nt8/NT%20HelpGuide%20English.html?developing_for__tick_replay.htm

Hope this helps, and doesn't have any typos/bugs !!

hyperscalper

Oh, for sure this helps.. You know I show friends the code I've written and it
blows them away generally... But when guys like you just print out concepts like
this in minutes it's probably just as amazing to people as ingenuous as myself.

I'm hoping this will get me started.. (so simple - luv it)..
I'll make a couple of tries at it and post if I'm stuck..

[EDIT]
Question - I've been under the impression that generally volume below zero or in
this case using dataPacket.bid and dataPacket.ask.. volume below the mid-point
would usually be counted as + positive volume.. no?
MM is buying from retail sellers no ?

Thanks friend - "Teach a man to fish"

Chuck

Chof 

Oh, for sure this helps.. You know I show friends the code I've written and it blows them away generally... But when guys like you just print out concepts like this in minutes it's probably just as amazing to people as ingenuous as myself. I'm hoping this will get me started.. (so simple - luv it).. I'll make a couple of tries at it and post if I'm stuck.. [EDIT] Question - I've been under the impression that generally volume below zero or in this case using dataPacket.bid and dataPacket.ask.. volume below the mid-point would usually be counted as + positive volume.. no? MM is buying from retail sellers no ? Thanks friend - "Teach a man to fish" Chuck

Hi,

Maybe you didn't mean that but, of course, there are no Real
Trade volumes of zero. In futures, it's 1 contract or more, with
no fractional contracts available.

We are using "signed volume" ONLY as a convenient way to distinguish
between "buy" and "sell" trades. We could choose any convention we
want to make that distinction, once we've categorized the trade as
being "buy" or "sell". WE KNOW that we're very rarely making mistakes
here, and have also discussed elsewhere that some Retail players use
Limit orders, and try to "buy the Bid" or "sell the Ask"; however these
are only a very small proportion of all trades, which we DISREGARD
as a significant source of error.

So you can use any convention +/- that you want to represent the
categorization of "buy retail trades, near the ask price" versus
"sell retail trades, near the bid price". Just as you can choose to
represent Net Buying on your chart as either UP or DOWN as you
wish.

And you should probably choose a "perspective". Are you going to
see things from 1) the Retail perspective, or 2) as I like to do, from
Market Maker's perspective. Whatever CONVENTION YOU CHOOSE,
just make sure it makes sense to you, and you stick to your own
conventions for calculations, etc...

In retrospect you could say I've "mixed" perspectives and
that you are perhaps right that we should say a "retail trade
to the bid" is a positive number, since MM is the Buyer and
so we represent that as positive, but it's just a convention...
It's just whatever is clearest to you, and also makes most
sense visually when you represent on a chart also.

I like to see Retail Sellers driving Net Inventory DOWN, and
that Market Maker is going to go against that when it is
far enough down. Market Maker is getting "long" (which
is traditionally what we say) on the Retention interval
timeframe; but Retail Players' cumulative inventory
is generally Net Short, or at least there's a predominance
of Retail Sellers, so...

hyperscalper