Possible issue with Buy, sell, and net volume

April 5th, 2019, 04:35 PM

I am really perplexed on the condition stated here and request some input.

I recently wrote and posted an indicator to plot buy, sell, net, and total volumes which was based on NT�s BuySellVolume (BSV) indicator. No issues with the indicator as is however, as I was writing another indicator to do more analysis on the buy and sell volume I realized there was something that I completely missed because I did not bother investigating why the BSV indicator categorized the trade volume as either a Buy or Sell. The basis for that decision can be seen in the code below (directly from the BSV indicator in a truncated form) which is in the OnMarketData section:

if(e.Price >= e.Ask)
buys += (Instrument.MasterInstrument.InstrumentType == � (truncated here)
else if (e.Price <= e.Bid)
sells += (Instrument.MasterInstrument.InstrumentType == � (truncated here)

While it looks pretty straight forward notice that both �if� statements test for the �=� condition. This would mean that when the condition is such that the Price = Ask = Bid the volume for that trade is put into the Buy Volume. If the order of condition test were reversed, then that volume under the same conditions would be Sell Volume.

Is this an arbitrary condition or is there a legitimate reason for testing in this order, a question I have raised with NT support (and have not heard back yet other than it is being investigated)? It seems to me that if there isn�t a legitimate reason for testing in this order that the volume, under the mentioned condition, would be skewed to the buy volume.
To see how prevalent this condition might occur, I modified the inprogress of Version 2 of my indicator with the code below (again truncated for clarity and in the same section):

if(e.Price > e.Ask)
buys += (Instrument.MasterInstrument.InstrumentType == � (truncated here)
else if (e.Price < e.Bid)
sells += (Instrument.MasterInstrument.InstrumentType == � (truncated here)
else if ( counter == 0 )
{
buys += (Instrument.MasterInstrument.InstrumentType == � (truncated here)
counter++;
buyCounter++;
}
else
{
sells += (Instrument.MasterInstrument.InstrumentType == � (truncated here)
counter--;
sellCounter++;
}

This code handles the Price=Ask=Sell condition differently by splitting the matches equally between the Buys and Sells, arbitrarily putting the even trades as buys and the odd trades as sells. It also counts the number of times each section of the code was entered for each bar which get printed when the bar is closed. The results surprised me.

Using a 300 tick bar (with tick replay) on over 5000 bars all but 3 or 4 matched the condition. This count included both historical and real time data with the historical making up a major part of the count. The screen shot shows how different the results are with only the code change above.

Unless I am missing something (entirely possible), the issue is that unless there is a justifiable reason for categorizing the trades that meets the condition as Buy volume then it must be arbitrary therefore is not justified. Does this or does it not call into question the value of even using buy/sell volume under these circumstances?

Thoughts!

April 5th, 2019, 04:46 PM

Cheech

While it looks pretty straight forward notice that both �if� statements test for the �=� condition.

Not so, one condition is testing for >= and the other is testing for <=.

i.e. the code caters for prices equal to or worse than the ask, and equal to or worse than the bid.

There are many ways to code this area but the original is an ok one.

April 5th, 2019, 04:51 PM

ratfink

Not so, one condition is testing for >= and the other is testing for <=.

i.e. the code caters for prices equal to or worse than the ask, and equal to or worse than the bid.

There are many ways to code this area but the original is an ok one.

Well, but what about the condition that I mentioned when Bid and Ask are both equal to Price?? It seems to me that the first "if" would detect the equal condition therefore put the volume in the Buy category.

April 5th, 2019, 05:08 PM

ratfink

Not so, one condition is testing for >= and the other is testing for <=.

i.e. the code caters for prices equal to or worse than the ask, and equal to or worse than the bid.

There are many ways to code this area but the original is an ok one.

Also, maybe you missed the part where the equal tests were removed from the NT tests and fell through to the added code. This would mean the neither the Price was > Ask nor the Price was < Bid, therefore both Bid and Ask were equal to Price.

That is the condition that I'm questioning.

I suppose one could question why the other possible conditions (Price < Ask or Price > Bid) weren't included in any test but neither of those would make sense to me in a completed trade.

Am I still missing something here?

April 5th, 2019, 05:51 PM

Here's my NT7 code (non=PC 'returns' because it's c30% faster)

Code

protected override void OnMarketData(MarketDataEventArgs e)
{
    if (e.Price == 0)
        return;
			
    if (e.MarketDataType == MarketDataType.Ask)
    {
        askPrice = e.Price;
        return;
    }
			
    if (e.MarketDataType == MarketDataType.Bid)
    {
         bidPrice = e.Price;
         return;
    }
			
    if (e.MarketDataType != MarketDataType.Last)
	 return;
					
    if (e.Price >= askPrice)
    {
        upVol += e.Volume;
        buying = true;
        return;
    }
			
    if (e.Price <= bidPrice)
    {
        downVol += e.Volume;
        buying = false;
        return;
    }

    if (buying)
    {
        upVol += e.Volume;
        return;
    }

    downVol += e.Volume;
}

As an aside I've stopped using OMD in more recent stuff and use separate Ask and Bid series in OBU where needed.

April 5th, 2019, 08:32 PM

Cheech

Am I still missing something here?

Just that Price can be in between a widened spread Ask and Bid (i.e. neutral and therefore not registered in some code variants), or equal to Bid or equal to Ask (and be valid Buys or Sells but therefore forced into your modified code arbitrary second version allocation scheme counters), or less than Bid or greater than Ask and be rightly classed as desperate Sells or Buys. Furthermore Bid/Ask should never meet or cross or the exchange screwed up. Notwithstanding OMD also gets hit with lots of other stuff as well as what you want to see, including zero prices (meaning unchanged Bid/Ask) from some datafeeds.

Hope that and the code helps, TGIF + beer or wine also does, Cheers @Cheech.

April 5th, 2019, 08:38 PM

ratfink

Here's my NT7 code (non=PC 'returns' because it's c30% faster)

Code

protected override void OnMarketData(MarketDataEventArgs e)
{
    if (e.Price == 0)
        return;
			
    if (e.MarketDataType == MarketDataType.Ask)
    {
        askPrice = e.Price;
        return;
    }
			
    if (e.MarketDataType == MarketDataType.Bid)
    {
         bidPrice = e.Price;
         return;
    }
			
    if (e.MarketDataType != MarketDataType.Last)
	 return;
					
    if (e.Price >= askPrice)
    {
        upVol += e.Volume;
        buying = true;
        return;
    }
			
    if (e.Price <= bidPrice)
    {
        downVol += e.Volume;
        buying = false;
        return;
    }

    if (buying)
    {
        upVol += e.Volume;
        return;
    }

    downVol += e.Volume;
}

As an aside I've stopped using OMD in more recent stuff and use separate Ask and Bid series in OBU where needed.

Sorry, maybe I'm being dense here but I would like to see those rules in English as I still don't understand what it is you are doing and under what premise. I'm not saying they are wrong or anything but it still isn't clear to me that when a trade is completed when Bid=Ask=Price as per the NT code under what rules can be it classified as either a buy or sell trade

April 6th, 2019, 05:14 AM

Cheech

Also, maybe you missed the part where the equal tests were removed from the NT tests and fell through to the added code. This would mean the neither the Price was > Ask nor the Price was < Bid, therefore both Bid and Ask were equal to Price.

That is the condition that I'm questioning.

I suppose one could question why the other possible conditions (Price < Ask or Price > Bid) weren't included in any test but neither of those would make sense to me in a completed trade.

Am I still missing something here?

I think it would mean that the Price was somewhere between the Bid and the Ask, not that the Bid and Ask were the same.

April 6th, 2019, 05:56 AM

ratfink

Just that Price can be in between a widened spread Ask and Bid (i.e. neutral and therefore not registered in some code variants), or equal to Bid or equal to Ask (and be valid Buys or Sells but therefore forced into your modified code arbitrary second version allocation scheme counters), or less than Bid or greater than Ask and be rightly classed as desperate Sells or Buys. Furthermore Bid/Ask should never meet or cross or the exchange screwed up. Notwithstanding OMD also gets hit with lots of other stuff as well as what you want to see, including zero prices (meaning unchanged Bid/Ask) from some datafeeds.

Hope that and the code helps, TGIF + beer or wine also does, Cheers @Cheech.

Sorry - newbie error - missed Ratfink's post!

April 6th, 2019, 06:06 AM

Cilla

Sorry - newbie error - missed Ratfink's post!

No problem, you clarified a point I only covered indirectly anyway.

Possible issue with Buy, sell, and net volume

Discussion in NinjaTrader

Possible issue with Buy, sell, and net volume