Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
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:
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):
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!
Can you help answer these questions from other members on NexusFi?
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.
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.
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, 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
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.
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.