IKTrading icon indicating copy to clipboard operation
IKTrading copied to clipboard

How to plot Ichimoku Cloud using ichimoku indicator, so as to render the future cloud in the chart?

Open knshetty opened this issue 10 years ago • 6 comments

Using the ichimoku indicator, I am attempting to plot Ichimoku Cloud, with the below implementation:

require(quantmod)
require(IKTrading)
getSymbols('IBM', src='google', from='2014-04-01')
ibm_ic = ichimoku(IBM)
ibm_icPlot <- ibm_ic[,1:5]
chart.TimeSeries(ibm_icPlot, legend.loc = "topleft")

After running the above code, all the five lines are rendered in the Chart (i.e. turning line, base line, Span A, Span B, plotSpan), here's the screenshot of my RStudio with the plot:

Alt text

Well, the problem is with the 'Span A' & 'Span B' lines (i.e. future cloud), which are not projected ('nMed=26') into the future. This projection is very important aspect of visualizing an Ichimoku Cloud in its entirety. Any suggestion on how to make the ichimoku indicator to plot the future cloud? Or is there something wrong in the above implementation?

knshetty avatar Dec 15 '14 01:12 knshetty

I don't use it for visualization. I use it as a trading indicator. It would also mean having to extend the xts object, which I'm not quite sure how to do.

On Sun, Dec 14, 2014 at 8:22 PM, Nash [email protected] wrote:

Using the ichimoku indicator https://github.com/IlyaKipnis/IKTrading/blob/master/R/ichimoku.R, I am attempting to plot Ichimoku Cloud, with the below implementation:

require(quantmod) require(IKTrading) getSymbols('IBM', src='google', from='2014-04-01') ibm_ic = ichimoku(IBM) ibm_icPlot <- ibm_ic[,1:5] chart.TimeSeries(ibm_icPlot, legend.loc = "topleft")

After running the above code, all the five lines are rendered in the Chart (i.e. turning line, base line, Span A, Span B, plotSpan), here's the screenshot of my RStudio with the plot:

[image: Alt text] https://camo.githubusercontent.com/921327536ba40a9424858a92d6a828afb495c177/68747470733a2f2f7075626c69632d6368333330322e66696c65732e316472762e636f6d2f79327065316730794a41374653454476465f3244396f3568664f6637447a454e6c756d5f4861414f6445653741615375356a4e4b6a35336c2d395342565363734755354467666c455548724a586737505453504b58514669534c6449622d4e546c53694a58504273654e466f69552f494b54726164696e675f496368696d6f6b75506c6f742e706e67

Well, the problem is with the 'Span A' & 'Span B' lines (i.e. future cloud), which are not projected ('nMed=26') into the future. This projection is very important aspect of visualizing an Ichimoku Cloud in its entirety. Any suggestion on how to make the ichimoku indicator https://github.com/IlyaKipnis/IKTrading/blob/master/R/ichimoku.R to plot the future cloud? Or is there something wrong in the above implementation?

— Reply to this email directly or view it on GitHub https://github.com/IlyaKipnis/IKTrading/issues/3.

IlyaKipnis avatar Dec 15 '14 01:12 IlyaKipnis

If you are using the ichimoku indicator as a pure trading indicator, the future cloud formation still needs to be inclusive. Because the future cloud helps to determine the market sentiment (i.e. a measure of equilibrium according to Goichi Hosoda), hence this future cloud can signal potential trend reversals that is either bullish or bearish, which can be a viable flag in an Ichimoku based Algo. A brief theory and application of pairing the 'SpanA' & 'SpanB' lines can be found here.

Well, this is my attempt to render the 'Span A' & 'Span B' lines (i.e. future cloud). Now, 'Span A' & 'Span B' lines are projected 26 periods into the future. This was achieved without any data-loss considering how the 'Span A' & 'Span B' data-points are calculated at present in the ichimoku indicator, I presume this data-loss is intentional for 'Span A' & 'Span B'... Is it?

Here's the implementation code & screenshot of the plot:

require(quantmod)
require(IKTrading)
getSymbols('IBM', src='google', from='2014-04-01')

ProjectTimeseriesToFuture <- function(dataset, projectionPeriod) {
    extendedIndex <- timeBasedSeq(paste(end(dataset),end(dataset),sep="/"), length.out=projectionPeriod+1)
    out <- merge(dataset, xts(, extendedIndex[2:length(extendedIndex)]))    
    return(out)
}

ichimoku <- function(HLC, nFast=9, nMed=26, nSlow=52) {
    turningLine <- (runMax(Hi(HLC), nFast)+runMin(Lo(HLC), nFast))/2
    baseLine <- (runMax(Hi(HLC), nMed)+runMin(Lo(HLC), nMed))/2
    spanA <- lag(ProjectTimeseriesToFuture((turningLine+baseLine)/2, nMed), nMed)
    spanB <- lag(ProjectTimeseriesToFuture((runMax(Hi(HLC), nSlow)+runMin(Lo(HLC), nSlow))/2, nMed), nMed)
    plotSpan <- lag(Cl(HLC), -nMed)

    out <- cbind(turnLine=turningLine, baseLine=baseLine, spanA=spanA, spanB=spanB, plotSpan=plotSpan)
    colnames(out) <- c("turnLine", "baseLine", "spanA", "spanB", "plotLagSpan")

    return (out)
}

ibm_ic = ichimoku(IBM)
ibm_icPlot <- ibm_ic[,1:5]
chart.TimeSeries(ibm_icPlot, legend.loc = "topleft")

Alt text

Comments & suggestions are welcome :)

knshetty avatar Dec 16 '14 03:12 knshetty

Looks good, actually. Thanks a lot =).

On Mon, Dec 15, 2014 at 10:03 PM, Nash [email protected] wrote:

If you are using the ichimoku indicator https://github.com/IlyaKipnis/IKTrading/blob/master/R/ichimoku.R as a pure trading indicator, the future cloud formation still needs to be inclusive. Because the future cloud helps to determine the market sentiment (i.e. a measure of equilibrium according to Goichi Hosoda), hence this future cloud can signal potential trend reversals that is either bullish or bearish, which can be a viable flag in an Ichimoku based Algo. A brief theory and application of pairing the 'SpanA' & 'SpanB' lines can be found here http://www.kumotrader.com/ichimoku_wiki/index.php?title=Ichimoku_components#Senkou_Span_A.

Well, this is my attempt to render the 'Span A' & 'Span B' lines (i.e. future cloud). Now, 'Span A' & 'Span B' lines are projected 26 periods into the future. This was achieved without any data-loss considering how the 'Span A' & 'Span B' data-points are calculated at present in the ichimoku indicator https://github.com/IlyaKipnis/IKTrading/blob/master/R/ichimoku.R, I presume this data-loss is intentional for 'Span A' & 'Span B'... Is it?

Here's the implementation code & screenshot of the plot:

require(quantmod) require(IKTrading) getSymbols('IBM', src='google', from='2014-04-01')

ProjectTimeseriesToFuture <- function(dataset, projectionPeriod) { extendedIndex <- timeBasedSeq(paste(end(dataset),end(dataset),sep="/"), length.out=projectionPeriod+1) out <- merge(dataset, xts(, extendedIndex[2:length(extendedIndex)])) return(out) }

ichimoku <- function(HLC, nFast=9, nMed=26, nSlow=52) { turningLine <- (runMax(Hi(HLC), nFast)+runMin(Lo(HLC), nFast))/2 baseLine <- (runMax(Hi(HLC), nMed)+runMin(Lo(HLC), nMed))/2 spanA <- lag(ProjectTimeseriesToFuture((turningLine+baseLine)/2, nMed), nMed) spanB <- lag(ProjectTimeseriesToFuture((runMax(Hi(HLC), nSlow)+runMin(Lo(HLC), nSlow))/2, nMed), nMed) plotSpan <- lag(Cl(HLC), -nMed)

out <- cbind(turnLine=turningLine, baseLine=baseLine, spanA=spanA, spanB=spanB, plotSpan=plotSpan)
colnames(out) <- c("turnLine", "baseLine", "spanA", "spanB", "plotLagSpan")

return (out)

}

ibm_ic = ichimoku(IBM) ibm_icPlot <- ibm_ic[,1:5] chart.TimeSeries(ibm_icPlot, legend.loc = "topleft")

[image: Alt text] https://camo.githubusercontent.com/c07a6fef45634c32e8682417103a8f7d1f843e0f/68747470733a2f2f686161716e612d6368333330322e66696c65732e316472762e636f6d2f793270724265375735464c3972305f4d64304b6d385041383338704347456a6f75773232514136516b68335f6b48376c766431732d766152504655624b316d7537755649706b79706c376f576969496e32754b30774368437530596866734d58426b3345314a4f4563646955356e79507948504b504d784f387430783535656550635a76444f3970645743572d6e4e30436d585a73494b32672f494b54726164696e675f496368696d6f6b75506c6f745f57697468467574757265436c6f75642e706e67

Comments & suggestions are welcome :)

— Reply to this email directly or view it on GitHub https://github.com/IlyaKipnis/IKTrading/issues/3#issuecomment-67105799.

IlyaKipnis avatar Dec 16 '14 03:12 IlyaKipnis

Hi, @knshetty

When I try your code, I get the following error: Error in lag(Cl(HLC), -nMed) : n must be a single positive integer

Wonder where did I go wrong?

debsush avatar May 21 '16 19:05 debsush

@debsush,

I found the issue lied in the order which you load dplyr package and the xts package. See: https://github.com/joshuaulrich/xts/issues/131

The quickest fix I found to be loading xts after or not loading dplyr if you don't have to.

Hope that helps!

Esturban avatar Aug 17 '16 14:08 Esturban

@Esturban

Many thanks. This was most helpful.

debsush avatar Aug 19 '16 09:08 debsush