OPEN-SOURCE SCRIPT
Trend Explorer
Diupdate
Are we in a bull or a bear market?
From the technical analysis point of view, the answer is "It depends". It depends from the parameters of your indicator, the timeframe of the pair you are looking and the volatility of that specific market you are looking to.
After I experimented with various trending indicators I decided to develop a framework that potentially could "embed" already existing logic from well known indicators (e.g. Supertrend OTT etc.).
The most important part is that I managed to abstract that logic away and experiment even further to produce some more robust, market and timeframe resolution agnostic results. While at the same time I was able to switch between market and timeframe resolution specific configuration to take some decision.
Finally, I decided to share this code with you folks! Developed this indicator "Trend Explorer" in an effort to make the aforementioned abstraction of all those trending indicators.
The goal is to enable the user to explore and combine different approaches in order to create a more robust and market general/specific, timeframe resolution invariant/fluctuating and volatility auto/manual adjusted indicator according to his needs.
The logic behind the abstraction is fairly simple. The trending indicator consists of two boundary lines the "bull trend low boundary" (green) and the "bear trend high boundary" (red). The indicator also has a control line (orange). Every time the control line crosses a boundary there is a trend reversal! The boundary lines are defined by the thresholds. To be more precise, boundaries are pulled upwards by thresholds (blue) during a bull market and downwards during a bear market. I challenge the user to experiment with the different ways of calculating the thresholds and the control. I am open to suggestions that might improve and extend the possibilities of this indicator. Any feedback, comments, general thoughts or bug reports are welcome.
Why did I chose those defaults?
For threshold calculation I chose MINMAX which calculates the local minimum and maximum using a sliding window. As far as I know it is not used in any existing trending indicator, but it seems reasonable for a trader to search for local min and max to make a decision. The width of the sliding window a.k.a the "period to remember" the local min and max is 30 days by default, just because I believe that for regular people it is a reasonable period of time to forget too.
Also, compared to the SUBADD method MINMAX does not seem to lag behind, especially when using averages in the SUBADD mode. Moreover, I consider MINMAX to be more general than the margins used by the SUBADD since margins should be configured based on the underlying market volatility.
For a source of min and max I chose the low and high values just because they are timeframe resolution invariant, meaning that they have the same (not exactly due to number precision and rounding, but very close) results for a single pair whether you use "4 hour" or "1 day" time interval! Another popular choice might be (close, close) since many traders wait for the daily candle to close in order to discard outliers. However, this approach is not resolution invariant and it depends from the time interval the user has selected.
Do you have any interesting trending indicator you would like to see how it performs in this framework logic? Let me know!
Do you have in mind any variation of Control or Thresholds calculation you would like to test? Please describe it in the comments below so I can add it in my implementation for you!
Did you find any other bug or you experienced any strange behavior? PM me with a description of the bug, the trading pair the timeframe resolution the exact time (candle) and all the necessary configurations for this indicator so I can reproduce it on my machine!
Please enjoy with caution,
Jason
From the technical analysis point of view, the answer is "It depends". It depends from the parameters of your indicator, the timeframe of the pair you are looking and the volatility of that specific market you are looking to.
After I experimented with various trending indicators I decided to develop a framework that potentially could "embed" already existing logic from well known indicators (e.g. Supertrend OTT etc.).
The most important part is that I managed to abstract that logic away and experiment even further to produce some more robust, market and timeframe resolution agnostic results. While at the same time I was able to switch between market and timeframe resolution specific configuration to take some decision.
Finally, I decided to share this code with you folks! Developed this indicator "Trend Explorer" in an effort to make the aforementioned abstraction of all those trending indicators.
The goal is to enable the user to explore and combine different approaches in order to create a more robust and market general/specific, timeframe resolution invariant/fluctuating and volatility auto/manual adjusted indicator according to his needs.
The logic behind the abstraction is fairly simple. The trending indicator consists of two boundary lines the "bull trend low boundary" (green) and the "bear trend high boundary" (red). The indicator also has a control line (orange). Every time the control line crosses a boundary there is a trend reversal! The boundary lines are defined by the thresholds. To be more precise, boundaries are pulled upwards by thresholds (blue) during a bull market and downwards during a bear market. I challenge the user to experiment with the different ways of calculating the thresholds and the control. I am open to suggestions that might improve and extend the possibilities of this indicator. Any feedback, comments, general thoughts or bug reports are welcome.
Why did I chose those defaults?
For threshold calculation I chose MINMAX which calculates the local minimum and maximum using a sliding window. As far as I know it is not used in any existing trending indicator, but it seems reasonable for a trader to search for local min and max to make a decision. The width of the sliding window a.k.a the "period to remember" the local min and max is 30 days by default, just because I believe that for regular people it is a reasonable period of time to forget too.
Also, compared to the SUBADD method MINMAX does not seem to lag behind, especially when using averages in the SUBADD mode. Moreover, I consider MINMAX to be more general than the margins used by the SUBADD since margins should be configured based on the underlying market volatility.
For a source of min and max I chose the low and high values just because they are timeframe resolution invariant, meaning that they have the same (not exactly due to number precision and rounding, but very close) results for a single pair whether you use "4 hour" or "1 day" time interval! Another popular choice might be (close, close) since many traders wait for the daily candle to close in order to discard outliers. However, this approach is not resolution invariant and it depends from the time interval the user has selected.
Do you have any interesting trending indicator you would like to see how it performs in this framework logic? Let me know!
Do you have in mind any variation of Control or Thresholds calculation you would like to test? Please describe it in the comments below so I can add it in my implementation for you!
Did you find any other bug or you experienced any strange behavior? PM me with a description of the bug, the trading pair the timeframe resolution the exact time (candle) and all the necessary configurations for this indicator so I can reproduce it on my machine!
Please enjoy with caution,
Jason
Catatan Rilis
- Optimize the calculations of the sliding window. So the min max values can be calculated for larger time periods without the "study error" due to the timeout from the TV execution engine. See (rlone9440 comment)
- Set more reasonable start and end dates for the sliding window even if the absolute values do not count. Only difference between dates is taken into account by the indicator.
Catatan Rilis
- minor refactoring
Catatan Rilis
- (minor) set control line width to 1
- add equality to Boundary conditions (prevControl <=> prevBound) in order to pull them to the trend direction in case of equality between control and bound
Catatan Rilis
- typo in tooltip
Catatan Rilis
- Fix some typos in the Style tab
- Fix some typos in the tooltips
Catatan Rilis
Did you ever watch the Bulls Vs Bears match and you wondered, Who is stronger right now? What's the score? Is any clear winner? If the answer is yes, then I have something for you. Look at the right top corner!In this game the players of each team (bulls and bears) will apply force to pull the opponent's control line towards their threshold line. The percentage of the pushback in the overall threshold range is the strength of each team. So the strength may vary from 0 to 100. The overall score is shown in the upper left corner of the table and may be from -100 to 100. The minus sign is for the red team. When the sign flips the tide is turning. However, to be sure that there is a clear winner the score should be more than 25 points in favor of one team.
Enjoy the match with the new update!
Catatan Rilis
- Update to pinescript V5
Catatan Rilis
- Happy New Year!
- Added the ability to set different sources for the base of bull/bear thresholds when the method is set to SUBADD
- Many code refactorings and optimizations
Catatan Rilis
- Add different ATR Length variable and do not re-use Base Length variable that take part in the avg base calculation when 'AVG' method is selected. However, when you use SUBADD Threshold method with AVG Base and ATR margins I propose to use the same length to prevent overfitting.
Catatan Rilis
- Add more average types options for control and base. Now, even more "complicated" trend indicators can be simulated by this framework.
- Currently the following average types are supported ['SMA', 'EMA', 'RMA', 'WMA', 'HMA', 'VWMA', 'SWMA', 'LINREG', 'MEDIAN', 'DEMA', 'TMA', 'VAR', 'WWMA', 'ZLEMA', 'TSF', 'TILL', 'HLAVG']. If you have any other avg in mind you want to see just let me know!
Catatan Rilis
- Add the ability to set this indicator as an external input to other scripts that support this functionality
- Add some tooltips to the table
Catatan Rilis
- Rename MINMAX to HHLL to better describe the higher high and lower low threshold functionality
- Margin can also be applied to HHLL method
- Add Ladder logic for ATR and StDev for the margin
- Settings group options have been reworked
- Code refactoring, optimizations, and reuse of internal libraries wherever this was possible
Catatan Rilis
- Use `series_collection` library
- Use enum
- Update ladder calculations
Skrip open-source
Dengan semangat TradingView yang sesungguhnya, penulis skrip ini telah menerbitkannya sebagai sumber terbuka, sehingga para trader dapat memahami dan memverifikasinya. Hormat untuk penulisnya! Anda dapat menggunakannya secara gratis, namun penggunaan kembali kode ini dalam publikasi diatur oleh Tata Tertib. Anda dapat memfavoritkannya untuk digunakan pada chart
Inggin menggunakan skrip ini pada chart?
📧 Contact info
Telegram: @jason5480
🔗 Addresses
₿ - bc1qxh3jeld7ke70fx3r5q243d96jsx0etth6x8fa7
* Please contact me before any donation ☕
Telegram: @jason5480
🔗 Addresses
₿ - bc1qxh3jeld7ke70fx3r5q243d96jsx0etth6x8fa7
* Please contact me before any donation ☕
Pernyataan Penyangkalan
Informasi dan publikasi tidak dimaksudkan untuk menjadi, dan bukan merupakan saran keuangan, investasi, perdagangan, atau rekomendasi lainnya yang diberikan atau didukung oleh TradingView. Baca selengkapnya di Persyaratan Penggunaan.