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)
Yes, of course, you could change the frequency with which property
file entries ("the properties") are read; or impose conditions, such as
detecting whether/when the file was changed, and then read again.... etc.
Surely, all that is possible.
But the actual read/parse and assignment of property values, is just such
extremely fast, and resource-sparing action; that I wouldn't worry about
it. You could change the Thread.Wait(....) timeout in milliseconds parameter
so that it does it every 5 minutes or so ( 5 * 60 * 1000 milliseconds).
I don't use a "Timer" mechanism; but it is simply a separate thread which
waits and times out, of course...
So, YES, certainly, you could try to read the file only when a change
in its contents occurred; but just checking for that "updated contents"
condition is most likely using resources, so are you really gaining
anything by adopting an approach like that ??
Don't get me wrong; I'm encouraging you to dive into Code and make
such improvements, but that would be an "optimization" which is
just entirely up to you. One thing I'd say is "Don't break the code,
trying to gain a millisecond of CPU"; keeping in mind that NinjaTrader
8 is Fully Multi-Threaded, and on modern processors, well they're
not Quantum Computers yet (LOL, like that's ever gonna happen) but
they are so fast that "in a blink of an eye" is really an old-fashioned
metaphor !! LOL
Time and Sales events, which we're processing; are not very "fast" events
in the grand scheme of things... On the other hand, where extreme
optimizations do make sense is when capturing Market Depth events,
which could be as high as 1 such event PER MILLISECOND; and then
you really need to start thinking "fancy optimizations" so you don't
get bottlenecks in your system !!! So "it's all relative" in a sense; and
of course keep your original copy; but if you want to change something,
again, that's THE WHOLE POINT of things is to get you deep into code.
[EDIT] RACE CONDITIONS can occur, which cause an error. The code I
provided should be "error tolerant". If the file were to be changed, in
the middle of a pass to read the property files, then at that particular
conjunction of events; my code is designed to be tolerant if an Exception
is thrown, and not just to crash. That's an unlikely "race condition"
but one you need to take account of... I just don't want my "property
reader thread" to crash !! LOL of course I haven't rigorously tested
that the code works, which is why "it ain't production code" necessarily
and is just "AS IS" ha ha ...
Thank you for reviewing my request and explaining the read process. I will just go on without making any changes. I will test your latest code on Monday. I am hoping it will be better than another simple crude script I have that simulates big lots.
JT
TWYS NWYT(Price Advertises Opportunity; Time Regulates it; Volume Measures its Success/Failure ---- Dalton)
Well, look, I sprinkled in a lot of "unconventional" things, that most
indicator writers might not do...
Now, here's an idea; As we move through the session, let's consider
that we could have 3 profile files for the 3 "periods" of activity or volatility.
Without restarting the indicator, you could just copy one of the 3 profile
files onto the primary file name to "shift gears" and tune the indicator
to the current conditions.
But we shouldn't be thinking about these "Nuts 'n Bolts" issues; when the
primary goal here is to extract a "real trade signal".
WHAT IF: We develop a simple Price MACD, and then we combine Price
Deflection with Risk in some advantageous way??? Those are the kind
of ideas we should be moving toward, just as an idea.
That's where we should be focusing our thinking !! Ever onwards
Good ideas. I will keep those in mind as I continue to research & analyze to get signals with these scripts.
In that regard I was comparing 2 instances of the TradeFlowRisk (I disabled the trailing dots) against one instance of the TradeFlowTutorial. (Please see attached chart and parameter details below). I was expecting the Blue and the Yellow plots to be fairly identical. But they are way different.
For some reason I am beginning to see more potential of getting signals using the TradeFlowTutorial, which is oscillating faster then the TradeFlowRisk. (By the way, the trade shown was not made based on these scripts, it was my AutoTrader using other type input signals).
Down the road, as my next task, I will be looking at incorporating and running 2 instances of either TradeFlowRisk or TradeFlowTutorial within the same script. Seems like a huge challenge for me, not having the expert programing skills you have.
Parameters used on the chart:
Green:
# your comment lines
RISK_THRESHOLD=10
RETENTION_SECONDS=120
MULTIPLIER=1
BIGLOT_MINIMUM=2
TAPER_SIZE=True
SUPER_SPIKE_THRESHOLD_RATIO=1.8
Yellow: (Same RETENTION_SECONDS and BIGLOT_MINIMUM as the BLUE plot).
# comment line
RETENTION_SECONDS=60
MULTIPLIER=1
BIGLOT_MINIMUM=5
TAPER_SIZE=true
TWYS NWYT(Price Advertises Opportunity; Time Regulates it; Volume Measures its Success/Failure ---- Dalton)
I'm glad you're getting into it. That was the whole reason for presenting
some code.
It is generally true that Net Inventory fluctuations do correlate with local
tops and bottoms. However, the concept of Risk is more significant, so
I'd encourage you to focus on that.
You can quantify "How much Risk?" in dollars, if you know the Risk delta
distance from Market Price in Ticks, times the Value of a Tick, times
a factor proportional to Net Inventory imbalance.
As I've said before, this ain't full Inventory Analysis, but it approximates
pretty well, and does relate to the concept of "How much Risk" Market Maker
is experiencing on the Time Frames which are described by the Retention
Interval.
Just sayin'... For a simple indicator; on a short term basis, it can be very
useful.
It addresses the core concept that Market Maker uses Retail Players to
"take a position" against them on the Long and Short sides, and dips
into "pseudo risk" at the tops and bottoms.
I say "pseudo risk" because MM is really taking no risks at all; as She manipulates
Retail players into Buyers and Sellers who are basically chasing the price trend.
So, many of you know this as "Order Flow" Analysis, but I'll
make the explicit distinction that Trades (Time and Sales)
are transactional exchanges of Inventory, so should be called
Trade Flow Analysis.
Orders are "on The Book" or the "Depth of Market" but do not
represent transactions; rather, they represent an "interest"
in making a transaction; a Bid or an Offer which may not be
taken. So "real Order Flow Analysis" is far beyond the scope
of this indicator; and beyond most Traders' reach; as it will
depend upon the Quality of the Market Depth.
Most brokerages give a "cheap" or "aggregated" or "limited"
Market Depth. Why? Traders don't really use it; and so there's
no reason to offer it. The Premium Market Data Feeds, such
as Rithmic and others; which might be used for Order Flow
or "DOM Analysis" are beyond what Traders are even interested
in; as they wouldn't know what to do with it..... 'NUFF SAID.
SO THIS IS NOT ORDER FLOW ANALYSIS, but it is Trade Flow
Analysis, and that depends upon using the Time and Sales only.
We can assume that most brokerages/data feeds provide an
Accurate Time and Sales; so this Indicator can be used by just
about any Trader.
WHAT IS THE VALUE OF THIS INDICATOR?
I may have said elsewhere; that Trade Flow, which yields a Relative
Net Inventory Imbalance, and some reference to Risk; is....
"A Situational Analysis". What does that mean?
It means that we can say to ourselves "Well, Market Maker is taking
Risk here" and that means She may be looking to Turn the Market.
BUT IT DOES NOT necessarily provide you with PRECISION as to
exactly where the Market Trend will turn.
Depending upon the Precision requirements for your own trading;
it is either Very Useful; or perhaps Inadequate if you require Very High
Precision on where the Trend Top or the Bottom exists.
SO IT'S USELESS? No, not at all... It's a very important "situational
variable" which informs you of Market Maker's Relative Inventory
"situation" and also potential "Risk" situation; and "that ain't Nuthin'"...
By the very nature of trading, Market Maker has "very deep pockets"
and so, when a Market is strongly trending; MM can push well beyond
any "reasonable" turning point.
So understand that this Technical Indicator; like many other technicals,
can be "swamped" by EXTERNAL factors (like the Market Open, etc
or News Events)... But when the Market is NOT primarily being driven
by external factors, then Technical Analysis such as this is Very Good,
at predicting turning points of a Market.
YOUR COMMENTS WELCOME !!! I'm trying to encourage you to jump
into code; but also to think about how you can design an Indicator
which implements Your Theory about what may be Predictive.
It will inspire a handful of you; if so, then it's worth the trouble, and
I'd encourage you to think about the Strengths and the Weaknesses
of any such Technical Indicator... and then think how it can be improved.
SPOILER ALERT: Everything can be significantly improved...
[EDIT] I'm running this thing myself... And attached is a screenshot of
how I use it.
and...
# comment line
RISK_THRESHOLD=12
RETENTION_SECONDS=600
MULTIPLIER=1
BIGLOT_MINIMUM=2
TAPER_SIZE=True
SUPER_SPIKE_THRESHOLD_RATIO=10.0
Note that I adjust the left margin, to fix the scaling so the Net Inventory zero
point is halfway, etc. NinjaTrader 8 charts are nicely flexible, so that
these "dragged overlays" can be adjusted to be less confusing.
[EDIT2] Note that the Dots showing RISK are relative to Price; and not relative
to the Net Inventory lines. Those written on top of Price, are the "Big Lot" sizes
which tend to occur also at tops and bottoms.
By way of emphasizing that Trade Flow is a "situational variable"
and also understanding that External factors will drive Market
Maker into Risk, without necessarily turning the market...
Attached is a screenshot where the Nasdaq shows an "irrational"
persistent (but false) breakout into Short Risk which can
risk a Trader's shirt and trousers.
This is a Friday; and on Fridays all sorts of "shenanigans" and
"dirty tricks" generally appear.
This is why I have chosen the Nasdaq futures contract as my
only target Instrument. Because it is "hands down" the most
difficult environment in which to consistently profit.
So, in posting this, it appears that my argument for the usefulness
of TradeFlowRisk as an Indicator, is revealed as weak or
potentially useless...
But, as I said earlier, "external" factors can push beyond where
a natural turning point should exist; and Trade Flow Analysis
should be considered a "situational awareness indicator".
After a 20-30 point Breakout, it was revealed as False; and fell
back. But unless you are a very Smart trader; this can take
you down...
As I said before it would be extremely beneficial to just remove the properties file altogether and store information in standard [NinjaScriptProperty] getters and setters. Then NinjaTrader handles all of that stuff for you, and you can take full advantage of NinjaTrader's features. Having an external file will break things like the Strategy Builder, AI Generate, or optimization backtesting.
Since they're just properties, the code can modify them at any time. If you want to modify the properties yourself you just open up the indicator properties. Reading and writing to file only happens when it needs to for saving the workspace. You'll really have an easier time if you work with the way NinjaTrader does things rather than reinventing the wheel.
Seth, sure everything you said is clear to me and others.
My work is Real Time only; therefore, I don't want to lose all
of the Real Time data accumulation; so I want to change key
properties, "on the fly" while the Indicator is running.
When you do it "the NinjaTrader properties way", of course
you have to scan through Historical, and then possibly flip
into Real Time every time you change a Property value; I think
that's how it works... and that creates huge problems with
complex Indicators which have significant "state"... Just sayin'...
I think I made that very clear; and my reasons are that much of
the information I need is NOT AVAILABLE from historical replay.
Not so much in the case of this indicator, but certainly for Depth
of Market replay, which is simply NOT POSSIBLE for the
events and analyses that I typically am looking at.....
The "NinjaScript way" is really great for "simple" indicators; but
when things get very critical and complex; in my experience, that
framework is just not good enough.
But, it's good enough for most traders; so I'd just count myself
as an exception, and one key factor for me, is that I don't do
Backtesting... Not that there's anything wrong with those of
you who *do* want to do Backtesting... I just have a different approach...
NinjaTrader could easily allow for Property changes; without resetting the Indicator
I'm pretty sure.... But they don't do that, AFAIK; maybe I'm wrong?...
[EDIT] I doubt that more than 0.1% of NinjaScript Indicator writers are aware that
multiple "object clones" are created on Indicator query and startup; and that's also
true for Strategy instances. These "clones" are distinct Object instances, and most
Indicator writers don't need to know that this cloning is happening; so long as they
keep things "simple" and also "stateless" as much as possible.
Properties can also be changed by code. If you really want to get fancy you can take advantage of some of C#'s unique features to add GUI elements to the chart, or create an pop out window for it.
Also, this little bit of code is useful outside of just the OnStateChanged method:
Not that tick replay ends up being all that different from live data except perhaps for 1 second timeframes. However, this is really useful because it enables the next solution...
Anything can be saved to a file and recalled historically. Then you can do real a real empirical study about what your changes are actually doing. You won't be changing things on the fly by hand very much either because you'll already know the optimal value for the situation.
But more importantly then other people can more effectively use the work to develop it further. It will play nice with other indicators, and you can use them in strategies.