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)
We designed and delivered a NinjaScript Indicator which estimates
various Order Flow features, called TradeFlowRisk.
So now I'd like to see who's interested in designing an Indicator which
helps to Pinpoint the precise turning point of short term Micro trends.
Right up front, I'm wondering whether it's worth the effort; not only
because there may be a lack of interest, but...
I work from the Rithmic Market Data feed, and not all data feeds
have the same quality, and also my work is exclusively with the Nasdaq Futures contract.
So, I need some level of interest before trying this, since it's not going
to be easy to take my algorithms, and put them into the simple
Indicator framework.
If there's enough interest; then I'll consider it. The effort could ultimately
fail, due to lack of market data quality, or the restrictions of the Indicator
environment; but it's perhaps worth a try...
There needs to be some enthusiasm, so I'll wait to see how many are
interested, who would want to learn the coding as well...
you are a rare fella hyperscalper
you have helped me and opened my eyes more
you have also been very helpful towards anyone asking a question and wanting to learn. I thank you for that.
John
THE HYPOTHESIS WHICH WILL LIE BEHIND THE INDICATOR
Background: I've been searching for what I'd call "The Holy Grail" and
that is the ability to do "Positive Continuous Trend Following".
Now, most people look at Price and try to both determine the Trend from
the Price, as well as to Predict the Future Trend Continuation from the
Price.
I've said before that "Price does not predict Price" and that something
else, which is Volume-related should be used to help predict future
Price movement.
(I've also conceded that certain "Price Patterns" like Head and Shoulders,
and other such things as Support or Resistance can help to predict future
Price; but it still remains true that "chasing Price" and hoping for
continuation, which means an "established Trend, expected to Continue"
is not likely to be very effective.)
HYPOTHESIS: When the Price is Trending Up, then there is a "Wave" of
Size at the BID which can be interpreted as Pushing the Price upwards.
Now, it's not actually "Pushing", but it is placed there by Market Maker,
just in case Retail Sellers want to SELL, so Market Maker can BUY, but
She has the intention of simply Buying ("Thank You very Much") but then
continuing to push the Price upwards, thus forcing a Higher Valuation
to what She just purchased. So we will compare BID size to size on the
ASK or Offer side; and we expect that BID will dominate Before the Price
moves upward. Why is size on the ASK diminished, relative to the BID ??
Obviously because, by hypothesis, the Price is moving upward, and so
our Market Maker has less interest in SELLing to any Retail Buyers, since
the Price is moving upwards, and not downwards...
THAT MIGHT BE A LOT TO CONSIDER, and I don't want to get into "the weeds"
about even more details, so let's just say a "Wave of BID size (relative to
ASK size) is associated with an UP Trend in Price". Also, a "Wave of ASK size
is associated with a DOWN Trend in Price" by symmetry.
I'd like to hear your reactions to this. Specifically, "Can it be that Simple?"
and my anticipated answer would be "No, it's not simple; but should be
measurable".
When you are comparing one side of the market with the other,
it might be natural to assume the expected value would be zero;
that the market is "balanced".
This, however, is not generally true.
So, we'll be measuring sensitive differences between BID and
ASK sides of the market, so we will need to handle the issue
of the Constant Bias.
Our plan is to maintain a moving Reference Averager, which will measure
the Constant Bias over a suitable period of time, like maybe 5 minutes
or so.
Our Bias measurements will then be Corrected by the value of the
Constant Bias.
There are many pitfalls to sensitive measurement in markets; and
this is just one of them !!
For this Indicator, at least in the first iteration; we'll NOT be
looking away from the Inside Market.
Not everyone will have a Depth of Market feed, or it is unlikely
that it's a high quality one (sorry about that, no offense meant)
so we'll initially see what we can do just with the Immediate
Inside Market.
For purposes of appreciating some of the Signal Processing
challenges, this will be enough of an introductory exercise...
In my own work, I analyze the Depth of Market; which shows
the behavior of Market Maker away from the Immediate
Inside Market.
"Single Contract" Bids and Offers appear on the Inside Market,
and these are of course "the Small Fish"; so why should the BID Price be affected by some Little Guy who happens to
place a contract's worth of size at the BID + 1 Tick ??? But, unfortunately
that's what happens when only the so-called "Level 1" data
is used so measure, for example, the Bid/Ask Spread in Ticks.
Just some considerations to keep in mind.
As i say, we'll try not to use Market Depth yet; but will use
"Inside Market Analyzers" which will tend to minimize the effects
of "Small Contract Pollution" by capturing data over a Window
of Time. This is another aspect of signal processing, where the
"signal" we're trying to find is the "Momentary Bias" which
will have an Expected Value of Zero difference; once we have
applied our Constant Bias Correction...
MNQ is generating an average of 1,550 events per second.
NQ is generating ... 1,245 events per second.
NO OTHER data series are incoming; the entire focus is on
NQ/MNQ .
Each event calculates a Price Specific lookup in a Dictionary
(HashMap type of structure) to get an Analyzer to handle
that event, etc. The minimum calculations need to be kept
in mind, in such a situation, as any programmer can realize !!
I don't need both Primary and Secondary data streams running
concurrently, so I'll want to switch off the unnecessary processing.
Just gives you an idea the Nasdaq Futures market data rates,
which are challenging, even for NinjaTrader's impressive speeds,
and my code optimizations.
This server is "co-located" within 1 millisecond network time of the
exchange, and incoming data is Queued, (double buffered) and
processed on another high priority thread so I can consume
as much data as possible ...
Compiled, fully Optimized C# can produce processing speeds which
approach C++ speeds, as intermediate code is compiled by the
CLR Runtime into CPU specific code, within the Virtual Machine, etc...
I have Custom charting, using a WinForms Charting package
from MindFusion, integrated with my NinjaTrader Strategy,
which also presents a WinForms User Interface.
The reason for this custom charting, is that I can Precisely
see the Indicator signals versus Time, which is NOT generally
possible with a NinjaTrader chart.
Without going too far into the weeds here, a NinjaTrader
Interval Chart is NOT REALLY a "pure" Interval Timebase
chart.
If no TRADE occurs in the Interval, then there is no BAR
generated. Apparently most charting packages do that.
So I can now visualize a TRUE Interval chart and see exactly
what are the Signals, and relative Price movements.
Whew !!! That was a lot of work for me, but the benefits
are that I can see very clearly exactly what the Signals
are, versus the Price.
The "pink" signals, some of which are Circled, are to be
interpreted as "Up means Predicted Price is Up". So they
are seen as a "push" of Price in that predicted direction.
You can see a couple of cases where the Predictions do
result in subsequent Price movement in the predicted
direction. BLACK line is Price (or really a compressed
Price) with a high resolution (actually the MID price
between the BID and the ASK prices).
INterested in the indicator and micro trend to scalp on reversals on NQ or MNQ even.
Yet to have read all the posts I Will get to reading it all and reply what my comments are.
I will help altough my knowledge is limited, though working on building out another Algo myself and made some headway but looking to improve my skills in WPF to allow create function of the settings inside the chart while leaving the Algo running while allow properties to be changed on the fly. Not sure where tp start tp learn how to enable functions of a custom button or properties setting inside chart window but alas rome was not built in a day and little else happens alongside those who never cease learning.
I plan to deliver something, which will use a properties file for adjustments in
the parameters as the Indicator is running. Will not be back-testable; only
real time modes, not historical.
If you are writing anything like a Strategy Interface, my recommendation is NOT
to use WPF, but to use a WPF "WinForms Container Control" and then implement
your interactive user interface in WinForms, in Visual Studio.
The NinjaTrader design for Strategies and especially Indicators, permits the
chart to kill "Terminate" the instance, and recreates another instance. You don't
realize this, necessarily, but it's a "killer" for a persistent user interface for a
complex Strategy. I have a Mega-complex user interface for my Order Entry
and Analytics, so I have to avoid any Strategy resets. Objects are even "cloned"
multiple times; and then eventually one of the clones survives to become the
running object instance. It's a bytch which I wish could be avoided.
The ultimate way to write a persistent facility is to write an "AddOn", which I will
eventually do; that will permit my Strategy to inherit from the AddOn's superclasses,
and then Charts will not terminate my Order Entry control, and it will be easier to
write reliable BOTs. FWIW, into the weeds, but just FYI.
