You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it is rather tricky to add a new line over the top of an existing candlestick plot because the current recipe converts the x-axis to a float range and then pastes the appropriate dates for labels.
This means that if a user attempts to add a new line to a candlestick plot they run into issues because the new line uses dates or datetimes for the x-axis, but the existing plot is using floating point numbers.
One possible solution would be to convert the datetimes for the new series to the appropriate float64's under-the-hood.
Alternatively, we could just use the original datetimes on the x-axis in the original candlestick plot. The issue with this approach (I think) is that given non-synchronous date or datetime inputs, it might be rather tricky to get fixed width candles across the plot while preserving datetimes as the data for the x-axis...
Code that reproduces the issue as it stands follows:
using Plots, MarketData, TimeSeries
gr()
ta = yahoo(:GOOG, YahooOpt(period1 = now() - Month(1)))
p = plot(ta, seriestype = :candlestick)
plot!(p, ta[:Open], seriestype = :line)
Currently, this code will squish the candles over to the left of the plot, while squishing the new line over to the right.
My best guess is that the under-the-hood solution of converting datetimes for the new series to the appropriate float64s will be easier, but it will be somewhat inelegant as we would probably need to parse the xlabels back to datetimes and compare in order to get the new series in the right spot in the general case. And if the user chose inputs that resulted in less than 2 labels displaying then the whole thing would fall over.
The text was updated successfully, but these errors were encountered:
Actually I was just thinking about this some more, and I don't think the floating point x-axis approach can work.
In the general case, every date/datetime from the original dataset used to construct the candlestick plot must to be stored somewhere, otherwise there will always be edge cases where approximations to align the new series and the original plot will get things drastically wrong.
So unfortunately a solution to this where fixed width candles is preserved is not at all obvious to me, unless plots has some mechanism for allowing a float-range for the x-axis, while simultaneously storing the corresponding dates/datetimes somewhere useful so they can be referred to later.
Requested ping: @mkborregaard
Hi all. Relevant julia discourse thread is here.
Currently, it is rather tricky to add a new line over the top of an existing candlestick plot because the current recipe converts the x-axis to a float range and then pastes the appropriate dates for labels.
This means that if a user attempts to add a new line to a candlestick plot they run into issues because the new line uses dates or datetimes for the x-axis, but the existing plot is using floating point numbers.
One possible solution would be to convert the datetimes for the new series to the appropriate float64's under-the-hood.
Alternatively, we could just use the original datetimes on the x-axis in the original candlestick plot. The issue with this approach (I think) is that given non-synchronous date or datetime inputs, it might be rather tricky to get fixed width candles across the plot while preserving datetimes as the data for the x-axis...
Code that reproduces the issue as it stands follows:
Currently, this code will squish the candles over to the left of the plot, while squishing the new line over to the right.
My best guess is that the under-the-hood solution of converting datetimes for the new series to the appropriate float64s will be easier, but it will be somewhat inelegant as we would probably need to parse the xlabels back to datetimes and compare in order to get the new series in the right spot in the general case. And if the user chose inputs that resulted in less than 2 labels displaying then the whole thing would fall over.
The text was updated successfully, but these errors were encountered: