Open jangorecki opened 10 years ago
I agree this can be further discussed to reach broader consensus on what makes for the best input structure and interface.
The relevant code is here: https://github.com/danielkrizian/rChartsDygraphs/blob/master/R/Dygraph.R#L99-L110
The dygraph()
wrapper takes care to break trades
argument down into entries and exits. It deals with the formatting details conveniently so that user doesn't have to. If you wish to assume finer control over how arrow annotations get drawn, there is possibility to supply own annotations/signals (further wrapping work can of course be done):
myChart <- dygraph(data)
myChart$setOpts(annotations=toJSONArray(signals, json=F))
I've chosen the compact trades
argument design instead of twin entry/exit arguments because in my workflow, the basic object of analysis is trade (paired entry with exit), not individual signals. What we are interested in is trade P&L - a metric of evaluation, as well as start and end. For trade analysis and calculation of trade-related statistics, I usually pro-forma close out any open positions and include the last trade in the analysis (unrealized P&L).
Will happily incorporate alternative points of view and workflows. If you know of any standard structure for storing trade/entry/exit data, let me know. Contributions, cases presented as reproducible code and pull requests are always welcome.
Exactly as you wrote it would be best to reach broader consensus. I'm not really orientated in any kind of common structures, similarly to you, I have own workflow, in my case I simply use vector of length of price
kind of c(0,0,1,0,0,-1,0)
where 1
are entry and -1
are exit.
Thanks for pointing the code responsible for that. Regarding the contributions the obstacle for me is js so contribution from my side will not happen anytime soon.
The only idea which comes to my mind is to make dygraph more modular by extracting parts of it functionally into separate functions, for example to have separate function to manage trades plotting:
dy <- dygraph(x)
dy <- dy + dygraph_trades(my_trades) # ggplot style
print(dy)
But it seems to be not a fast fix but kind of code redesign. Such separate function can be (more) easily customized by additional arguments and also (more) accessible for contributors. Just to emphasize, your package gives the best time series plotting in R. Thanks!
Ideas like you've just provided in the snippet above are extremely helpful, as they bring the perspective. It is indeed possible to accommodate different styles by composition:
dy + dygraph_signals(c(0,1,0,0,0,0,-1))
print(dy)
dy + dygraph_trades(my_trades)
print(dy)
dy + arrows(paramlist) # more generic
print(dy)
I like this separation of concern (or layering, if you will) so that we can have generic plotting isolated away from trading domain-specific plotting (trades, signals, etc)
Currently working on other priorities, hence contributions (even non-js, R-level wrapper code, or even well thought-out pseudocode demarcating function signatures) could speed things up.
Hi, Would it be possible to extend functionality of
trades
argument indygraph
to accept other kinds of signals? It's current structure is quite specific, I would prefer to just pass entry/exit index positions to be plotted. Additionally as far as I understand the currenttrades
is limited to plot only closed positions, user cannot plot an entry point if that point haven't got exit yet. Is this currently usedtrades
object any kind of popular structure for storing entry/exit stats?