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)
Hello, a possible solution would be telling you that the previous candle close if the bid vol is "bearish" adds to the sales, and the vol. of ask subtracts purchases, and vice versa, according to the closing of the previous candle.
I'm not a programmer, can you code it for N8 ???? Thank you.
Can you help answer these questions from other members on NexusFi?
There isn't really a problem needing a solution, only a misunderstanding.
I'm not currently working with NT8 but the code ideas are just the same, in the code I posted the 'buying' flag does what you suggest with a candle close, only tighter. I would think there are plenty of other correct NT8 solutions already out there, sorry I can't help more at this time.
I want to make a vol indicator, but I'm not a programmer, someone can help me ... I've been in the markets for years and I'm looking for a way to "know or approach" contracts that are not closed and that are stuck ... for N8
Thank you, Ratfink. I also have a question about onMarketData, but it's a little "involved" so might take me a while to work out a clear description of my issue - I'll put it as a separate post.
I thought about some more after the post and realized I made an incorrect assumption that they would be equal and gave it more thought. There are a number of possible combinations of Bid$, Ask$, and Price tests, some of which I believe to be irrational. So, I changed the code to test for Bid = Ask just to see if that condition really occurred and although in the test that I ran the counts of that condition were in the minority (but did occur) the rest would fall into some other categories some of which would be the in between category you mentioned.
Knowing what I do now I will do individual tests for each of what I believe to be "rational" combinations while still counting the others and see what happens. If no counts show up in either the other category or what I tested as a rational combination then between the two at least I would have identified the "rational" combinations that could occur.
The next thing would to be determined what might be rules for counting the volume as either a buy or sell for each condition and see how it matches to what the NT code does now. I suspect that the only fall out would be the original issue of the Bid=Ask = Price condition, which although it does not happen frequently (at least with the ES), it does happen. For that condition I have no idea why one choice (buy vs. sell) would be more correct than the other.
Also, the test was using historical data (with tick replay) which may or may not be the same as the real time data, potentially a whole other issue.
*** Update ***
Just finished the additional combination tests. Checking again 30 days of tick replay data against the ES there were hits on 3 conditions; (1) Price equal ask and Price Greater than Bid, (2) Price Equal Bid and Price Less than Ask, and, (3) Price equal to both Bid and Ask.
Concerning the last condition of the 44,000 plus bars processed (unknown number of trades, there were only 85 hits with a volume of 9,907 against a total volume of 2.8 M, a very small percentage. I'll collect some data on real time trades but unless something is amiss I suspect it too will have a low percentage. With such a small percentage of hits I doubt NT will make any changes so unless something is radically off with the real time data I'll consider this issue closed.
As I just posted in another thread the point being missed is that the relative position of Ask and Bid is only relevant when the Last event occurs, regardless of how many times or where either or both of them move prior to the next Last event. Hence the need for local variable storage for correct handling.
Thinking more about this issue it would seem that we are missing the time precedence factor, such that in the case where Bid = Ask = Price is *really* seen, then it must be the most recent event change that takes precedence (i.e. whichever of Bid or Ask changed right before the Last event. That should take the arbitrary factor out of the volume allocation that you have seen.
As such the NT8 OMD interface cannot be used in its object form (with e.Bid and e.Ask delivered concurrent with the 'Last' event e.Price) and it must be used in the old NT7 manner with a new precedence flag needed for both versions. (Here I am assuming that NT8 does also deliver separate events for Bid and Ask as well as Last in the same way as NT7.)
It may of course just be a historical data artefact (which NT8 was supposed to correct with millisecond timestamping since NT7 is flawed in both Historical and Market Replay modes for Bid/Ask behaviour).
However this NT8 caveat:
Prevents this issue being addressed in Tick Replay mode anyway, since we cannot separate the order of Ask and Bid arrival - end of story.
Regardless of historical data issues the time precedence should be usable in NT7 and NT8 in live running, although in the grand scheme I agree it is not likely to be a big deal, but it is more interesting than I first thought.
