Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ichimoku Indicators #36

Open
codeplea opened this issue Nov 30, 2018 · 2 comments
Open

Ichimoku Indicators #36

codeplea opened this issue Nov 30, 2018 · 2 comments

Comments

@codeplea
Copy link
Member

codeplea commented Nov 30, 2018

I moved this post by @yageek to its own issue to invite discussion. - codeplea

By working on the Ichimoku's family indicator, I'm facing some questions about the API.

I'm using wikipedia as the reliable source of informations.

According to Ichimoku Kinko H,
the family of indicators contains 6 members:

  • Tenkan-Sen:
    Average of highest and lowest prices over a T_ts period.
    Standart value: T_ts = 9.
  • Kijun-Sen:
    Average of highest and lowest prices over a T_ks period. Same method as Tenkan-Sen.
    Standart value: T_ks = 26.
  • Chikou Span:
    Backward projection of close prices over a T_cs period.
    Standart value: T_cs = 26.
  • Senkou Span A:
    Forward projection over a T_ssa period of the average of Tenkan-Sen and Kijun-Sen.
    Standart values: T_ssa=52, T_ts = 9 and T_ks = 26.
  • Senkou Span B:
    Forward projection over a T_ssb_proj period of the average over a period of T_ssb_avg of the highest and lowest price.
    Standart values: T_ssb_proj=52 and T_ssb_avg = 26.

According to different sources( https://www.investopedia.com/terms/i/ichimoku-cloud.asp - http://stockcharts.com/school/doku.php?id=chart_school:technical_indicators:ichimoku_cloud - https://www.daytrading.com/ichimoku-cloud) computing any ichimoku indicators implies using the standart values. This remark and the inter-dependencies of indicators lead
me to some questions:

  • Do we offer the possibility to the user to customize the different period values (T_ts, T_ks, T_cs, T_ssa, T_ssb_proj, T_ssb_proj and T_ssb_svg)?

I was thinking to offer the possibility to the user. In case he passes a NULL option parameters, the standart values are used.

  • Do we create one function by indicator or should we create one uniq indicators that outputs all the values at once?

I would propose to create one function per indicator. In the case of Tenkan-Sen and Kijun-Sen, we may use one private function with two public aliases, as the computation
process is the same.

Any feedback on this?

Originally posted by @yageek in #35 (comment)

@codeplea codeplea mentioned this issue Nov 30, 2018
@codeplea
Copy link
Member Author

@yageek I moved your comment to a new issue for discussion.

These are interesting points that require thought, and I'm glad to see you're thinking about it.

Ultimately, if someone wants to do an Ichimoku Cloud with different options, I think we need to support that. I personally use Tulip Indicators with an optimizing back-tester which adjusts indicator options to find the optimum strategy. So even if options are very standardized, it would be best to allow adjustment.

I was thinking to offer the possibility to the user. In case he passes a NULL option parameters, the standart values are used.

I do not want to do that. It could work well for these indicators, but then, for consistency, I would need to implement that for all indicators. The idea of a standard option doesn't work well for most indicators. IMO, it's the responsibility of the library user (e.g. charting program) to provide good defaults.

Do we create one function by indicator or should we create one uniq indicators that outputs all the values at once?

Since Tenkan-Sen and Kijun-Sen (and Senkou Span B?) are actually the same function, it would probably be better to only implement one of them.

I think for Chikou Span, Senkou Span A, and Senkou Span B, which are normally back/forword projected, we will have to provide the values for the current bar, and the user (e.g. charting program) will have to do the offsets.

I am very opposed to returning data for a current bar which relies on a future data in anyway (back projection). The reason is that many are using Tulip Indicators with machine learning in an automated way. They have a program which tries many indicators, with many options, and automatically finds a winning system. However, if an indicator includes data from the future, then you have a data leak. This is why I've never implemented the popular Zig-zag indicator.

Anyway, I think it would be good to implement:

  1. Tenkan-San indicator, which you have already done, and which can be used to calculate Kijun-Sen and Senkou Span B. I would like to see this implementation modified so that it only passes through the input data once (Look at stoch.c as an example indicator that maintains highest/lowest values over a period.)

  2. Ichimoku Cloud indicator which calculates everything in one data pass. It would need to take as options the period for Tenkan-San, Kijun-Sen, and Senkou Span A. If Chikou Span is only close prices, it could/should be omitted.

So those are my thoughts. Let me know what you think.

@fdk0
Copy link

fdk0 commented Sep 1, 2019

Hello guys, I was wondering if there is an ETA for the release of the Ichimoku Cloud indicator, but I wanted also to thank you for the great job you are doing for maintaining and updating the tulip indicators.

Thanks and cheers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants