Trend Explorer

٢٩ يوليو ٢٠٢١

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

٢ أغسطس ٢٠٢١

ملاحظات الأخبار

• 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.
  

٩ أغسطس ٢٠٢١

ملاحظات الأخبار

• minor refactoring
  

١١ أغسطس ٢٠٢١

ملاحظات الأخبار

• (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
  

١١ أغسطس ٢٠٢١

ملاحظات الأخبار

• typo in tooltip
  

١٥ أغسطس ٢٠٢١

ملاحظات الأخبار

• Fix some typos in the Style tab
  
• Fix some typos in the tooltips
  

٣ سبتمبر ٢٠٢١

ملاحظات الأخبار

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!

١٢ أكتوبر ٢٠٢١

ملاحظات الأخبار

• Update to pinescript V5
  

١ يناير ٢٠٢٢

ملاحظات الأخبار

• 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
  

٤ يناير ٢٠٢٢

ملاحظات الأخبار

• 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.
  

٢٧ فبراير ٢٠٢٢

ملاحظات الأخبار

• 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!
  

٢١ مايو ٢٠٢٢

ملاحظات الأخبار

• Add the ability to set this indicator as an external input to other scripts that support this functionality
  
• Add some tooltips to the table
  

١ مايو ٢٠٢٣

ملاحظات الأخبار

• 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
  

٣٠ سبتمبر

ملاحظات الأخبار

• Use `series_collection` library
  
• Use enum
  
• Update ladder calculations