New features added:
1. The script chooses a lookback period that matches the timeframe. This feature can be switched off in the inputs, allowing the user to enter the lookback manually
Remarks on the connection between lookback and timeframe: The lookback should i.m.o. be equal to the ‘look forward’. Examples: If you choose a minute chart, you probably are a day trader and you wish to estimate where the quotes might go in the next hour. Then you should choose a lookback near 60, because the cannel will then provide the range and the COG generated by the previous hour and show the relative place of the current price in this range. If you choose an hourly chart, your horizon is probably a few days, so 35 is a proper choise, If you choose a monthly chart, you might want to estimate possibilities for the coming half year, so 7 is a proper value for this argument. The scrips chooses multiples of seven due to some superstition of mine. The script values reveal my personal subjective opinion, so the user can choose other arguments.
2. The script chooses a width that matches the lookback period. This feature can be switched off in the inputs, allowing the user to enter the width manually.
Remarks on the desirable width of the channel: The ‘landscape’ of the channel is meant to encompass most candles with some of those touching the border, then one can reasonably claim that the channel shows the ‘natural range’, providing an argument to call and ‘overbought’ or ‘oversold’ if candles move outside. Interdependency with lookback is caused by the fact that both the COG and the natural range are relatively wider when the lookback is further. However because this is not a linear connection, it took me a few hours to create a non linear formula that seems to works fine.
3. A feedback label is created to show the values that are used for lookback and width and whether these originate from the script or the user. This label can be switched off. The standard arguments label provided by Trandingview only show input defaults or entries while the compiler blocks attempts to change these with the script, so some other way to inform the user on the actual values for these parameters was needed.
The purpose of these additions is that you can throw the KeltCOG in whatever timeframe without worries about the proper settings. e.g. you can toggle through different timeframes trusting that this channel remains relevant.