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)
There is an easy Job to Do:
If an IndicatorLine ist rising, mark it in a different Color as if the Indicator is falling. Unfortunately there are some Problems and Questions - and perhaps some serious Coding-Traps in NT-Code
At First a general Note about Painting: Painting on the Chart slowing Down your Trading-System - therefore be aware, to use only necessary Drawing-Objects on your Chart. Like a slope- or a Signal-depending coloring of an Indicator.
In the attached Code you will find three different Methods to calculate the Slope and one easy-to-understand - and hopefully not ressource-intensive - Method to Plot a different colored Indicator-Line: If the Line is rising, it would be painting green, if it is falling it will be painting in red and if the slope is less than a Threshold, the Line will be painting in white.
Unfortunaly all three Methods dont work!
As you can see below, the attached Code shows an average RSI with a colored IndicatorLine - but also a rising Indicator is painted in red, and a falling indicator is painting in green
Here are my Questions:
1) What goes wrong with the Code?
2) Do you know a less ressource-intensive Method for Painting?
Coloring an indicator by slope is pretty simple. Let us assume that you want to color the first PlotSeries of an indicator, which is called Values[0]. Then you need to define two colors, "upColor" and "downColor", which you use for coloring the slope.
You will then need to take into account three cases: rising slope, falling slope, zero slope. Here is the code
Attached is an example for an indicator, which colors the indicator plot and the paint bars based on slope.
The Syntax for the Plot-Command:
PlotColors[x][y] = z;
x = Value or "Plot-Index" of the plotted Line (you have defined it in the Properties-Region of the Code)
y = Offset or "Bars Back" of the plottet Line (<--- this was wrong in my Code!)
As Attachment you will find the corrected Codesample.
Next I will give some example for ressource-saving Programming...
Perhaps somebody have some suggestions?
If you create an indicator, it should be coded in a consistent way. Your approach to use the ticksize for normalizing slope is inconsistent. Why?
(1) An indicator should have the same or similar settings for different instruments. Or do you have to set the overbought level for the RSI to 30 for ES 03-12 but to 20 to YM 03-12?
(2) Further an indicator should have the same or similar settings for different timeframes. You do not want to use different settings on a 60 min chart then on a 1 min chart.
An example for a royal failure of coloring slopes is the MASlopeMulti V2.83 indicator, which can be found here. It uses the ticksize for normalization and what you get is simply inconsistent. @Erez: The indicator is excellent, I am just talking about the idea to use ticksize for scale normalization.
Below are attached two charts to show how that inconsistency plays out. The first chart compares YM 03-12 to ES 03-12. YM's ticksize relative to volatility is 2.5 times smaller than the tick size of ES. Due to that smaller ticksize, you will notice that with identical indicator settings
-> YM always shows larger angles than ES
-> the neutral zones are much smaller than for ES
-> the percentage of rising and falling zones over the chart is higher than for ES
The second chart shows a 60 min chart of YM with the same settings. The neutral zones now have disappeared altogether, because they are so small that they will not even survive the change of an angle between two bars. Also note that on a 60 min chart, all angles are much larger than on a 5 min chart.
Conclusion: The ticksize is not suited at all to normalize slopes and angles.
If we want to define a neutral zone for the slope, we have to check the slope against volatility. This can be done by using any measure for volatility, for example
But don't use the ticksize. Attached is an example of an experimental study to color the slope of the midband and the channel lines of the Bollinger Bands. The indicator uses the average true range to normalize slope and has a number of options. For example you may color the channel lines according to their own slope, or according to the slope of the midband.
This indicator is consistent across instruments and timeframes. You can use the same setting for YM 03-12 and ES 03-12, irrespective of their different tick sizes. And if you apply that indicator to a 60 min chart of YM, the neutral zone will not dissolve into nothing. Chart and indicator attached.
@Trendseek: Would like to know, whether you will apply that method to the RSI.
As promised, here comes a code-example with ressource-optimized code for calculating our Custom-RSI-Indicator and Plotting the Results on the Chart. You will find the new Indicator-Version attached at this posting.
Beside Questions aboute Code-Optimizing Issues aboute a suitable adaption of the Slope-Calculation is the second Focus, setting by this Thread. Thanks @Fat Tails for his critical and helpfull advices about diffent Methods for a better definition of the neutral-Zone. All of them has advantages and disadvantages - like the TickSize Methode. I will discuss this below.
Lets outline the Main Points of our new Custom RSI-Indicator:
b) Plot- Print- and Draw Methods are ressource-intensive. Use them rarely, they will slow-down your System-Speed dramatically!
c) If possible, use Core-Indicators directly (via initalisition) to speed up your System (--> see the latest Code-Example)
Second Topic: For a proper use of slope-depending coloring use an adaquate THEORY-DRIVEN method to normalize the Slope-Value, that could be founded on volatility-related Aspects of the Indicator and the Chart.
In our Example the RSI is a standardized Indicator. It does not access on Instrument-related aspects like TickSize or the used Timeframe.
Because of the fixed Range of the RSI (the values oscillate between 0 and 100) we even need no more Information about the Volatility.
Below you see a Chart with our latest RSI-based Indicator:
Our theoretical thoughts about the volatility of the Indicator and the standardization of the slope are simple:
The RSI is a standardized Indicator - you dont need the TickSize of the Instrument or the Volatility of the RSI-Values. The RSI-Values oscillate between 0 and 100 or 30 and 70. (<--- This are the thresholds). For our Example the Range is: 70 - 30 = 40.
Therefore "40" is our Base to normalize the Slope-Values for the avgRSI and middleRSI. If you like, you can insert an adjustment, to consider the higher "smoothness" of the middleRSI and the SD-Bands which will result in lower slope-Values (I dont do that).
---> With this standardization -multiplied with 100- the rise and decline of the Lines between the Bars ( - the slopes - ) could be read as percentage.
Next time I (hopefully) will discussed, (1) how we could insert Tradingsignals into the Code, and which kind of Signal-Presentation are suitable for a ressource-optimized Indicator-Code. (2) Second I spend some more thoughts about the advantages and disadvantages of the different Methods for Sloping.
Great discussion. I totally agree. Indicators are applied across many different instruments and they should "behave" the same way regardless of the instrument.
Your point hits home about angle. I have seen this calculated many different ways but haven't thought much about the consistancy. I think I convinced myself to use "Ticks" rather and "TickSize" or Price in calculating angles. When I first thought of it, it seemed to not agree visually on the charts (if plotted), but seemed to make sense from an "Apples to Apples" comparison across instruments.
Do you agree with this approach of do you feel there is a better way to calculate slope?
"Slope" does not exist on scalable charts. The concept "Slope" refers to print outs and was used 50 years ago when charts were printed and neither the time scale nor the price scale were ever changed.
Slope is just a visualization of momentum
Let us take a 20-period SMA. Then the slope of this SMA is the visualization of
-> slope = (last value of SMA - prior value of SMA) / (time between two bars if the chart)
On a chart with a fixed time scale, the denominator never changes, so slope is a proxy for
-> last value of SMA - prior value of SMA = last price - price twenty bars ago = momentum
This shows that slope in the end is just a visualization of momentum, nothing else. With electronic charting software nobody needs angles and slope boxes, you just need to measure momentum. Momentum is the first derivative of price and measures the price change.
Normalizing price change means to compare the price change to the average or the typical change. This means that you have to divide price change by volatility. Volatility can be measured by the average true range, the average range or the standard deviation or any comparable measure.
Ticks are not suited to normalize momentum or slope
But ticks or tick size are not at all suited, because the ticks do not reflect volatility. A simple example shows that ticks do not work:
The daily ATR(20) of ES currently is 16 points or 64 ticks. The daily ATR of YM currently is 139 points or 139 ticks. If you compare the slope of a moving average for both instruments, you should approximately find the same result, as both instruments are index futures and are highly correlated. However, if you divide by the number of ticks, you will have a problem, as YM moves 139 ticks per day, and ES only moves 64 ticks per day.
Therefore you will find much larger angles for ES as compared to YM, which is obviously nonsense.
Forget the ticks, you cannot use them for normalization. And best forget the concept of slope, angles and remember that they were just used to visualize momentum, when charts were printed.