Open codeplea opened 5 years ago
@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.
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.
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:
T_ts
period. Standart value:T_ts = 9
.T_ks
period. Same method as Tenkan-Sen. Standart value:T_ks = 26
.T_cs
period. Standart value:T_cs = 26
.T_ssa
period of the average of Tenkan-Sen and Kijun-Sen. Standart values:T_ssa=52
,T_ts = 9
andT_ks = 26
.T_ssb_proj
period of the average over a period ofT_ssb_avg
of the highest and lowest price. Standart values:T_ssb_proj=52
andT_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:
T_ts
,T_ks
,T_cs
,T_ssa
,T_ssb_proj
,T_ssb_proj
andT_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.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 https://github.com/TulipCharts/tulipindicators/issues/35#issuecomment-443157498