Designing higher timeframe tools is challenging. Particularly when you want to apply the higher timeframe lookback to the viewing timeframe.
Here are the problems you run into when you want to use a higher timeframe input:
I designed this function to automatically calculate the number of candles back that you would need to go back on the timeframe you're viewing to cover the lookback distance on the higher.
It checks if there's a letter on the end of the string and cuts it off, leaving just the number, then converts it from a string to a number.
From there it converts the viewing timeframe and higher timeframe into minutes, divides the two to determine their relationship to one another, then it multiplies the lookback distance of the higher timeframe with the factor and the output is the higher timeframe lookback distance converted into the equivalent bar count on the lower timeframe.
I tried to write it in a way that would make what the function does clear to coders and non-coders so it can be modified to suit your purpose. My initial use case was to us this as way of determining a lower timeframe offset for lines that were cast based on previous high timeframe bars. You could use it for any kind of MTF indicator where you want to know how many bars back you need on the low timeframe to achieve the higher timeframe equivalent. For example, if you wanted to create a multi-timeframe moving average, you would use the output as the length of the moving average.
I used a tuple output for the purpose of demonstration, but this can be reduced to a single relevant output.
Hope you find it useful. It's nice when you don't have to fight against multiple resolutions.
Let me know what you think. Is there a better way to go about it?
Trade well.
Here are the problems you run into when you want to use a higher timeframe input:
- The output is a string.
- On the daily, weekly, or monthly timeframes, the output of the input.resolution variable is "1D", "1W", and "1M".
- The 1 minute, 1 day, 1 week, and 1 month timeframes all have an output of 1. Same for the 2m, 2d, 2w, 2m and so on.
I designed this function to automatically calculate the number of candles back that you would need to go back on the timeframe you're viewing to cover the lookback distance on the higher.
It checks if there's a letter on the end of the string and cuts it off, leaving just the number, then converts it from a string to a number.
From there it converts the viewing timeframe and higher timeframe into minutes, divides the two to determine their relationship to one another, then it multiplies the lookback distance of the higher timeframe with the factor and the output is the higher timeframe lookback distance converted into the equivalent bar count on the lower timeframe.
I tried to write it in a way that would make what the function does clear to coders and non-coders so it can be modified to suit your purpose. My initial use case was to us this as way of determining a lower timeframe offset for lines that were cast based on previous high timeframe bars. You could use it for any kind of MTF indicator where you want to know how many bars back you need on the low timeframe to achieve the higher timeframe equivalent. For example, if you wanted to create a multi-timeframe moving average, you would use the output as the length of the moving average.
I used a tuple output for the purpose of demonstration, but this can be reduced to a single relevant output.
Hope you find it useful. It's nice when you don't have to fight against multiple resolutions.
Let me know what you think. Is there a better way to go about it?
Trade well.
ملاحظات الأخبار:
Critical Update:
In testing I was so focused on getting the multi-timeframe aspect working right, that I didn't test the "Same as Chart" option in the resolution menu, which caused the function to return "na" because well... "Same as Chart" isn't a resolution at all. So I suppose there's four problems with doing multi-timeframe scripts that include the input.resolution variable.
Added the code and reorganized the function to take care of that issue too.
In testing I was so focused on getting the multi-timeframe aspect working right, that I didn't test the "Same as Chart" option in the resolution menu, which caused the function to return "na" because well... "Same as Chart" isn't a resolution at all. So I suppose there's four problems with doing multi-timeframe scripts that include the input.resolution variable.
Added the code and reorganized the function to take care of that issue too.
ملاحظات الأخبار:
No so critical update:
When you update the script, you update the screenshot.
Instead of a description as the last screenshot was, here is an application.
The color gradient is applied to an RCI() to determine a trend color
The RCI value is highly dependent on the lookback distance. This is the same 10 minute chart, but it has a 4h EMA 15 overlaid on it.
The RCI bar color is based on the 15 period RCI on the 4h chart, which is 240 bars. (15 bars x 240m chart) = 3600m divided in to 10m periods = 360 10m bars.
Thus the RCI length is an RCI(360). And though price looks sideways to down, we're actually in a 4h uptrend in the S&P.
What the included function is doing is determining how many bars back the RCI() should include in order to capture 15 4h bars.
When you update the script, you update the screenshot.
Instead of a description as the last screenshot was, here is an application.
The color gradient is applied to an RCI() to determine a trend color
The RCI value is highly dependent on the lookback distance. This is the same 10 minute chart, but it has a 4h EMA 15 overlaid on it.
The RCI bar color is based on the 15 period RCI on the 4h chart, which is 240 bars. (15 bars x 240m chart) = 3600m divided in to 10m periods = 360 10m bars.
Thus the RCI length is an RCI(360). And though price looks sideways to down, we're actually in a 4h uptrend in the S&P.
What the included function is doing is determining how many bars back the RCI() should include in order to capture 15 4h bars.
ملاحظات الأخبار:
Upgrade to v5.
Condensed it a bit. But it does the same stuff. Use prior version for v4
Condensed it a bit. But it does the same stuff. Use prior version for v4
ملاحظات الأخبار:
- It compiles as an overlaid indicator now to give two moving averages you can play with and see how the different inputs produce different outputs.
- A label appears above the bar that is the first bar the average would be calculating from (or otherwise stated, the number of bars back on the viewing timeframe necessary to span the bars back of the desired lookback length on the higher timeframe).
- Some cosmetic updates for the sake of the compiling and viewing.
- Important: the bars back output was a float, don't ask me why I did that. The output is now an integer and can be used for lookback lengths.
- Also Important: A runtime error has been added if you try to make the indicator look for the bars back of a period length LESS than what you're viewing.