Added signals and some examples

[jangorecki]

I've added signals argument to dygraph which accept data.frame with c(1,-1) signals.

1: buy, green, up
-1: sell, red, down

Also add some examples and put few parenthesis for better code folding in RStudio.

[timelyportfolio]

tested the examples in Readme.md and in man; very nice features

[danielkrizian]

Many thanks for sharing, I will review & merge shortly! One note, following @ramnathv 's style writing rCharts, I'd try to stick with the = assignment symbol instead of <-, following these considerations (especially Matt Dowle's comment in the second link): http://blog.revolutionanalytics.com/2008/12/use-equals-or-arrow-for-assignment.html http://stackoverflow.com/questions/1741820/assignment-operators-in-r-and

[jangorecki]

I was not aware of = in that matter. Always glad to learn new things. I'm fighting with multiple signals on input (+ custom arrow colors), it works well but there are some (very few) arrows are not displayed at all, they exists in ann. If you know any dygraph open issue for that let me know. And the signal's arrows are lagged according to my local timezone vs base data in UTC which makes debugging harder, strange it affects when I try to plot multiple signal but not the single as in current pull request.

[danielkrizian]

Would you mind adjusting the pull request then? Also, any particular reason for this style? The red seems more compact, but willing to learn best practices.

Without having looked at the demo examples yet (assuming they expose the missing arrows misbehavior), have you tested whether this alleviates the problem?

[jangorecki]

Yes, I will update, I will try yet today to solve multiple signals to put support for that also. If I failed today I will update current commit for single signal. Regarding parenthesis, it is very helpful when folding code (at least in RStudio) so you have each section of code in separate folded block. After you fold each subsection you should find it more readable. Let me know if you prefer to have style from your last commit. Missing arrows are related to multiple signals, so will not be visible in current latest commit. I'm just formatting the code and should update for multiple signals soon and expose a case with missing arrows.

[jangorecki]

I've update pull request for support for multiple signals, below the issues I've must mention:

1. timezone issue may shift the signals arrows vs it's series (ex. moving averages crossover), examples are on daily granularity so it should not be problem there, but when using hourly it may/is.
2. missing arrows occurs at least when arrows from two signals overlaps in the particular moment in time, after you run last example (multi signal) try this:

sig <- signals[Date %in% as.Date("2010-07-29"):as.Date("2010-08-04")]
dt <- data[date %in% as.Date("2010-07-29"):as.Date("2010-08-04")]
setkey(sig,Date)
setkey(dt,date)
sig[dt]
# compare to dygraph chart

So far I don't have any solution for this. Also it is yet possible there exists some other exception when arrows are missing, at least it seems on my production data. As long as I'm not able to prepare reproducible data lets not focus on that.

[danielkrizian]

I understand that the issue with multiple signals is not that the arrow is missing, but that one arrow overlaps the other precisely. There is a parameter available in JavaScript code to control the distance of (arrow) annotation away from the line. Offsetting one of the signal arrows more than the other would make both arrows visible. Just thinking aloud. Other solution would be to break and isolate control over elements like we've discussed before, something like: dygraph(...) + signals(signaldata1, offset="20px", colorset1) + signals(signaldata2, offset="10px", colorset2) + trades(tradedata)

[jangorecki]

Yes, it is related to overlapping, not missing (at least as long as I'm not able to reproduce any other cases). Quite fine suggestion about the offset, the higher frequent signals (sig_fast from example) might have smaller offset, the lower frequent signals would have higher offset. Regarding the both mentioned issue, it is possible that both would also affects trades, but it is to confirm on hours granularity and with multiple trades series (not supported yet?). I'm glad my pull request was merged.