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)
CRITICISM OF MY PARAMETERS FILE APPROACH,
and the usage of files in general.
So, I've taken a lot of expected criticism
that I'm not doing things "the right way"
when it comes to using NinjaTrader 8
startup Properties.
The argument is that my choice of putting
variable properties into a "properties file"
is too non-standard, and it doesn't permit
"optimization" which is a part of "backtesting"
of indicators.
Backtesting has as a goal, in part, to find
"the sweet spot" for parameters by "iterating"
through various choices and find the choices
that "work best". In some cases, this can
degenerate into "garbage in" / "garbage out"
in the absence of a hypothesis or theory as
to why an indicator signal level should be predictive.
(LET'S NOT FORGET THE BASICS. In Trading, you
Win, ONLY when you are able to Predict future Price
action, based upon detection of events now, or
the recent past. Excessive Trade Flow Risk levels
are hypothesized to Predict a Trend change. If
they don't, then they are not going to Make You
Money.)
In the worst case, this "optimization" can be bad,
in the sense that we choose parameters
which have "worked in the past" and then
we hope they'll continue to work in the
future. That can also degenerate into Desperation,
trying in vain to find something predictive through
backtesting... But I digress...
The naive trader may believe that this approach
is a good idea, but I can't go into all the ways that
this is deceptive, and perhaps counter productive
in ways that are not that obvious. WITH AN INDICATOR
you need a theory behind the WHY. Why do you expect
this indicator to be predictive? Is it measuring something
"special"?
I could go on and on about Traders' reliance on Generic
Indicators, mostly based on Price action; which give a
false sense of Hope to a Trader. Most generic Indicators
are not going to help you make Money. But that's MY PERSONAL
OPINION ONLY; and I don't want to push it on anyone else.
That's one thing. ANOTHER THING is that
when an Indicator starts up, it first feeds
Historical data in, and then it switches to a
RealTime mode for data going forward.
Specifically, the TradeFlowRisk Indicator
requires that the Bid and Ask prices at the
instant of the Trade be ACCURATE; and this
is difficult to achieve with Historical data.
In fact, special coding is needed to improve
that accuracy for the Historical phase of
Indicator startup, and it will never match
Real Time accuracy. (So, I ask "Why Bother?")
AND THE WORST THING OF ALL, is that when
you change any Parameter value; the Indicator
instance is RESET and Cumulated data is LOST.
You are expected to retrieve/restore your
data from the Historical feed which we just
pointed out, is INACCURATE for the data
which TradeFlowRisk is specifically targeting.
TAKING ALL THESE THINGS INTO CONSIDERATION,
I wrote the Indicator to take RealTime Data only,
where there is full accuracy; and when you want
to Fine Tune or change Parameters in any way,
you do it through.........wait for it !!
....the simple Text Editing of a Parameters File,
which the code periodically reads. This does not
disturb the RealTime Cumulation behavior of
the Indicator and I think it's a SIMPLE and
obvious way to provide a User Interface that
allow for changes to parameters as the Indicator
continues to run.
WHAT IS THE USER INTERFACE? It's a Text Editor
which works on the parameters file.
NOW, LET'S TAKE THE APPROACH A LITTLE BIT
FURTHER. HOW ABOUT THE ISSUE OF TRIGGERING?
Again, one approach for reasonably efficient Signal
Triggering, is to just put a Trigger Signal into a File,
which some other software is reading...
Reading and Writing to a text file, continues to be
a simple and effective way to communicate.
So if we are considering how an Indicator might be
used to trigger a Strategy to initiate trading, I'm
simply saying that File based communication could
be a reasonable way to do that, in a Custom System.
The way you're gathering 'volume' data by using data.packet volume
is the fastest way I've seen to 'sign' and consider the information in
subsequent calculations. This change from using 'bar' volume is what
changed the markets. It used to be that the 'Market Maker' could take
over when a market swung in their favor (I'm talking 15 years ago).
Those were the days when platforms like 'Tradestation' that allowed backtesting actually could provide an edge. (That was when I started)
But you're methods are proving the MM does this at their peril these
days. It seems they have to be considering other factors at all times.
The 'other factors' like news and reports were always there.. The
influences that take over when the participation drops are what makes
each of our styles propietary and we all have our opinions on what drives
a market other than price..
I used to use a 'collections' method to store volume data from a 'seconds'
chart and plot it in a tick chart in Tradestation through a 'function' that I
wrote and shared in the TS forums - mid 2000's.. (hey and that was "leading
edge" - at the time Tradestation couldn't plot volume information in a tick chart)
but it never led to a 'tradable edge' that I ever found..
that's all trivia.... but using an 'api' was possible back then and
traders would often use it to do calculations in "excel" and pass the order
execution data back to TS..
So, your use of text files is something I haven't seen shared before.. It
must be faster than using "excel". For sure its effective and not everyone has
"excel".
My initial reaction is that you're playing with what I call "Big Lot" directional
trades here; and those can be quite indicative, especially in the context
of Net Inventory being Long/Short so-to-speak.
When there's been an excess of Retail Buyers (MM Short Inventory) and then
Big Lot Retail Buyers start coming in to BUY; then you have a Reversal signal...
When there's been an excess of Retail Sellers (MM Long Inventory) and then
Big Lot Retail Sellers start to appear to SELL; then you have Reversal as well...
The usual explanation for this would be that these Big Lot Retail traders see
an opportunity for Breakout or Breakdown; and are "buying/selling too high/low
respectively".
Also, higher Rates of Trade (per unit time) will appear at these pivot areas as
well, in general.
I've said it before; and who can stop me from saying it Again !? Inventory
Analysis is "situational awareness" and we need to be prepared for FALSE
Breakout and Breakdown "run through" of the theoretical Trend turning Price
point; but that's useful information.
You've undoubtedly noticed that I take "Counter-Trend" trades, wanting to
Sell the highest, and Buy the lowest; and therein lies a danger of some
Price Adversity, so be prepared for it.
[edit] I forgot to mention the concept of RISK; since that's the idea
the MM is "losing money" on Cost of Inventory (temporarily); so
looking at the Risk Level estimates is even more predictive of a
turning trend, I'd suggest.
[edit-attachment] You can see the Big Lot Selling as the overnight
session begins, with the RED meaning Retail Selling, and Blue being
Retail Buying. On that chart the PURPLE line is Net Inventory on a
15 Second moving window of time. A 20 Point lift follows the circled
corresponding times with a Ninja chart above, and custom charting
below, at around 17:06 (Chicago) on the chart. Obviously from this, MM trades
AGAINST Big Lot Retail Traders. But BLACK lines are a "compressed"
representation of Price, where true Price can be seen on the Ninja
chart on top of the screenshot.
Hey hyperscalper, I think that in a bigger scheme of things, your way makes a lot of sense. It is a very simple and robust way to transfer parameters from an external research pipeline to a running algo.
I'm going to read your threads here and your code to understand the idea behind. I'm trying to combine "order flow" with the info on the dom for a better insight in how the market is guided. I.e. try to gauge the general direction the mm is pulling towards. Perhaps something good can come from this.
Thanks for the good words. Oddly enough, and I'll most
likely never get into Live Depth of Market Analysis in
this forum...
I could be the world's "alleged Expert" on Retail Trader
DOM Analysis, so there's that... LOL What we've been
doing in this thread on Traded Volume analysis is "child's play"
when compared to tackling the DOM, just to give a sense
of perspective...
Trying to understand the DOM is more or less "ridiculously difficult"
and I've done that work for many years now.
C# multi-threading, Queues, Dictionaries, Custom samplers,
Price level specific stabilizers, Anti-Spoofing; and
the list goes ON and on....... LOL true; which is why nearly
nobody has ever tussled for very long with a real Un Aggregated
Depth of Market, most likely
I use the Rithmic Depth of Market which extends out way more
than 60 Tier levels on either side, and can exceed more than
1000 updates per second easily....
So if you want to start another thread and start asking how
to handle "The Deadly Beast" which is the DOM, and in my
case it's the Nasdaq futures contract DOM; then be my guest
Could you show me where I could get the RJay's indicators that you show on your chart. I might be overlooking them but I can't seem to find them for NT8.
Ok, I'm up to date now. I read it all and took notes
I'm not sure I'll contribute much in terms of code, other than the quick mod/hack, as NT is not my platform of choice.
Some of the reasons is precisely the limitations and inadequacy of such platforms in scenarios you describe above.
Many years ago I went "full in" and I'm using only my own platform.
This means mostly C and C++ for trading and backtesting. For quick idea tests, statistics and general research I'll drop into python.
I used R before and Matlab/Octave before R. You get the idea.
So, let's come back on the theme of inventory. Have you considered using a "global" inventory "integrator" over multiple contracts?
For example NQ and MNQ combined? Or do you assume that territory taken by the arbitragers, so one contract is enough?
The scenario is that MM sells X contracts of MNQ and buys Y NQ cashing in the spread with no inventory change (i.e. any unmatched inventory from each contract will be regulated in cash at expiry).
Maybe this is HFT territory and MM has no interest in going into this?
Sorry, you may consider switching to NT8, and turning
your world upside-down... LOL
Yes, I have a "global inventory integrator" over ALL contracts
in a single symbol; although not "merging" across symbols.
Clearly NQ and MNQ trade differently; and one of the two of
them is "the driver contract" but I usually look at the NQ, but
can easily look at either/both.
Arbitragers have nothing to do with much, but it's true that
NQ and MNQ will be constrained to be very close in pricing;
and arbitraging may have some role there...
My "full inventory analysis" does "full matching" of ALL lower priced
Buys with higher priced Sell volumes; thus removing "closed
inventory" profit, from remaining "open inventory"; the latter of
which is used to calculate the "true VWAP", Risk, etc. lol
