You can clone with
No one assigned
Not sure if possible to do in a generic way. But maybe will make sense once we have an OHLC aggregator implemented
Yes please implement candlestick plotting for DataFrame. It is so nice to make instant plots of financial data from yahoo with pandas but candelstick charts for many, like me, really are a must to analyze the data.
I'd be happy to accept a pull request for this
I have this here:http://nbviewer.ipython.org/4982660/
In order to support financial data I send mpl an ordinal index, essential np.arange(len(df.index)) and draw the ticks with a Locator/Formatter. Doing this with DatetimeIndex actually speeds up plotting #1579 and gets rid of weekend gaps. However, a side effect of this is that you have to keep the previous data around for future plots on the same axes. For that I have a Figure class that handles translating any future plots into an ordinal index. I chose to keep all plotted data around for plot specific fillnas, but that's probably unnecessary.
I'd like to merge this stuff in but I'm not sure how compatible it is. trtools.charting is fairly heavy handed in assuming you're not touching matplotlib directly. Mixing ordinal and datetime index plots on the same axes wouldn't work.
The module itself is self-contained outside of a small column_grep utility, so it can be made to be cleanly import-able as an add-on.
@dalejung, if you could find a way to merge your code it would be greatly appreciated.
@dalejung, have you had any luck implementing this?
I agree that importing a big library for something like a candlestick plot seems heavy handed, maybe there's a lighter weight way we can get this going.
@wesm, how do you think this should work syntactically?
Rolling this functionality into plot might be neat.
For example, if the DataFrame has a datetime index and columns "open", "high", "low", "close", and a DataFrame.plot() is called, would it make sense for the result to be a candlestick plot by default?
Would this be better as a kwarg for DataFrame.plot() or as a separate function (e.g. ohlc_plot)
@woodb Sort of. I split out the charting work into its own project https://github.com/dalejung/ts-charting. The heaviness was due to me keeping the plotted data around in a DataFrame. I was doing this to use the DataFrame.__setitem__'s auto-reindexing to keep the plots aligned. I'm a bit smarter now and keep only index around.
I think ts-charting should be straight-forward to merge into pandas, at least a portion of it. When I get the time I'll open a PR.
@dalejung Prima, let me know if you need any help, I've got some time here and there.
@woodb Actually, a smaller first pass could be done with http://nbviewer.ipython.org/5864433. That uses the matplotlib datetime handling.
ts-charting converts the DatetimeIndex to ints and translates the labels back with a custom Formatter. I'm pretty sure this could be made pandas compatible by always checking the current ax for our TimestampFormatter and reindexing to the current x-axis. I suppose the Figure and Grapher classes would need their methods refactored into flat functions or hidden away onto the Formatter.
Converting to an int-index is better but it means that every plot to that ax will need the translation. It's convenient to call fig.hl_span("2012-01-02", "2012-01-05"), but the base matplotlib method would not work ax.axvspan("2012-01-02", "2012-01-05") unless I monkey patched it.
Actually, thinking about it more. I dunno if that's acceptable for inclusion into pandas. Part of the reason for the Figure abstraction is to create a namespace where all methods are aware of the Datetime -> int translation. hm.
Thought y'all might be interesting in this:matplotlib/matplotlib#2643
If merged, you'll be able to feed a matplotlib axes object a list of dictionaries "stats" describing the boxplots via a bxp method
Thanks @phobson. Worth noting that mpl already has candlestick support pretty much baked in,
But it's planned for removal in a future release?
@y-p -- yeah. What I've heard is that matplotlib.finance will be deprecated in mpl 1.4 and removed by 1.5.
@phobson , is it getting a new home or will the code just be thrown away?
The fragmented state of python viz has been coming up in issues here lately.
The situation is eerily similar to wes's old post on the fragmented state
of data libraries in python, hoping for a similar turn for the better.
@phobson new champion for a combined viz library? (built on pandas of course) :)
I was discussing this out of band with @olgabot. @mwaskom 's seaborn could be a good candidate (and it already appears to use pandas).
@y-p I can't say for certain what the final fate of it is. My impression, however, is that it'll be thrown out.
Personally, I think pandas/pydata people/we should be equally supporting/endorsing/contributing to seaborn and python-ggplot.
I got in early on matplotlib straight from using matlab during my stint in academia -- which is to say I'm comfortable using it directly and I probably won't ever get my head around ggplot-esque APIs. However, I think having both styles of API is crucial to growing the python-science/data/viz community.
poignant comment made a few days ago re two valid approaches: mpl recipes vs. ggplot.
I don't know which library will come out on top (hopefully both), but we should encourage viz PRs
to join forces with existing efforts rather then pandas sapping work away IMO.
Note: @phobson just beat me to it :)
You might, I've been thinking of doing the same thing except targeting ggplot.