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:
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.
Notas de prensa
⋅
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.
Notas de prensa
⋅
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.
Notas de prensa
⋅
Upgrade to v5. Condensed it a bit. But it does the same stuff. Use prior version for v4
Notas de prensa
⋅
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.
Here's why: You don't get an accurate number if you look for the bars back on a lower timeframe. If you are looking at the 15m and you say "How many bars back would I go to get the 5m SMA20?" Well, its a nonsensical question really. But the answer would be 6.6667. So, you could make it 6 or 7. But, I struggle to see a use case for a 6 period lookback. Maybe you have one. We can always add it later. For now, you'll get an error.
This looks very useful but i'm not sure what the lb input is... could you clarify?
kurtsmock
⋅
@DannyBaker, Hey Danny. lb was what I used to indicate "Lookback" so its the lookback length in the higher resolution. For example a lookback of 10 bars (<-- _lb) on the 1h timeframe = 20 bars on the 30m (<-- _bb output).
What you're doing is entering the resolution of interest and the lookback length on that resolution, then calculating how many bars back that equates to on the timeframe you are viewing. Useful for higher timeframe calculations if you, for example had a security call that pulled daily data but you want to match the lookback on the viewing timeframe of 1h of another function or input, answering the question "On this timeframe, how many bars back is 10 days ago on the 1h timeframe?" Because of how TV handles strings this is a lot harder than you'd like it to be.
DannyBaker
⋅
@kurtsmock, I'm sorry kurt im still a bit beffudled.. would there be a way to put the proposed HTF as one input then the current TF as the other input? i'm just not understanding the lookback period...
DannyBaker
⋅
@DannyBaker, what is 1 lookback period a measure of?
@kurtsmock, thanks but thats not useful for my application. I have made a vwap with the function you created, which works but the settings are not clear to me, i know what a lookback is normally, a setting of 1 is one bar back so in a 30 min chart that would be 30mins 2 bars would be 60 mins back etc. But the way you explain your lookback input it does not do that.
kurtsmock
⋅
@DannyBaker, Here's what the output looks like. You're choosing a timeframe and how many bars back you want to calculate on that timeframe. (code -> )
kurtsmock
⋅
@kurtsmock, Example use is you have an indicator that runs on a higher timeframe. Like in the case of the moving averages. You're on a 1m chart using a 5m moving average. But then you want to determine another quantity such as the CCI using the same distance back, but on the 1m timeframe. So your htf moving average is looking 10 bars back... 10 5m candles back. You can't use a lookback of 10 for the CCI because that will only use the last 10 1m bars of data.
What you're basically doing is synchronizing viewing timeframe indicators with the same lookback as a higher timeframe indicator. Useful in the event that you want to add more data to your higher timeframe measurements. A 10 bar look back on the 5m timeframe uses 10 data points. Extrapolate that on the 1m and you'd use 50 data points (the closing price for the last 50 bars). In one way you're adding noise, but because you're lookback distance is so much farther, by virtue of it being scaled to a higher timeframe, you're smoothing out the noise. Or said another way, you're adding noise to find signal.
Also I should point out that this was written before the release of some of the more advanced resolution arguments now built in to pine.