ENH: other plotting tools via plot accessor

[rhiever]

• scatter_matrix (deprecate, redirect to seaborn)
• andrews_curve
• parallel_coordinates
• lag_plot (maybe rename to lag)
• autocorrelation_plot (maybe rename to autocorrelation?)
• bootstrap_plot (maybe rename to bootstrap?)
• radviz

I think it would be nice to allow scatter_matrix to be called directly on a DataFrame. Currently, scatter_matrix is a separate function that takes a DataFrame as a parameter, but it seems like it would be easy enough to rework to allow it to be called directly on a DataFrame as well. Effectively, the convenience function would look something like:

def scatter_matrix(self, ...):
    pandas.tools.plotting.scatter_matrix(self.data, ...)

Is this feature feasible?

[TomAugspurger]

We could probably do this as DataFrame.plot.scatter_matrix. I'm not sure why this wasn't ever folded into the df.plot(kind=) function.

Also, the standard disclaimer that seaborn does this better

[jreback]

actually prob all should be added via the plot accessor: http://pandas.pydata.org/pandas-docs/stable/visualization.html#plotting-tools

[shoyer]

Something to consider: Maybe we want to deprecate some of these more complex plot types? For example, seaborn does a better job of scatter matrix than we do...

[jreback]

absolutely let's do that. any others?

bootstrap, autocorrelation, lag for statsmodels?

cc @jseabold
cc @josef-pkt

[rhiever]

@shoyer: IMO the scatter matrix is a basic plot type that people would want to see for a DataFrame.

[jorisvandenbossche]

I agree with @shoyer. These plotting methods are rather 'neglected' lately. I think we should either choose to give them more attention, or deprecate them. And personally I think it should not be the focus of pandas.

But maybe scatter_matrix as the IMO the most generic of the plotting methods listed can be the exception?

[jreback]

why don't we defer scatter_mattix to seaborn anyhow? so seaborn becomes an optional dep)

[josef-pkt]

@jreback how well are optional circular dependencies no supported in various packagings?
I haven't kept up with it, but we get circular dependency pandas - seaborn - statsmodels.
I'm in favor of tight integration, in general.

I'm not a heavy pandas user directly, but I also find some quick plot methods convenient, instead of having to look for the appropriate function in another package.

about plots in statsmodels: plots are mostly in a minimal maintenance state. There is not much effort for a style update to make them look better, e.g. compared to seaborn, because of a lack of developers.
However, we need them in support of the models and other stats functions and still keep adding more.
For example, acf and pacf are some of our oldest plot functions and won't go away.

Trying to use seaborn as optional statsmodels dependency to upgrade plots is an idea but doesn't have a champion to look into it and work on it. For many plots the focus of seaborn is exploratory analysis which is more similar to the pandas use, but for us having a model inside the plot is inside out because we need plots inside the models, or after having estimated a model.

[jreback]

using seaborn (or sm using pandas is no problem here)
you can simply import inside the method itself

[jseabold]

I'm in favor of not duplicating efforts and seaborn take over "statistics-driven" plotting in general. I do agree that quick and dirty DataFrame.plot for basic matplotlib plots is still useful, of course.

[datnamer]

@jreback @jseabold What about bokeh? Is there going to be a stats plotting effort there in the new chart interface?

I think that has more potential (for interactive data exploration like ggvis and due to engineer time) than seaborn.

[josef-pkt]

@jreback I was thinking more about the install process, pip, requirements and various distributions. Are those all smart enough by now, or will there be, at least temporary, problems?

In statsmodels all plot functions try except protect matplotlib import, but we would still have to watch out for circular module imports when statsmodels reuses seaborn. However, that's a internal problem not a distribution problem.

[jreback]

well I have been pushing the engine=seaborn | bokeh | mpl | pandas for a little bit. IOW for the 'standard' ones, we have an implementation and just defer if the user passes engine. For the ones we don't have an impl, then have to defer.

Ideally we would remove all plotting code from pandas (except for say resampling callback and such). And just defer to various engines.

You can do this now via .pipe, this would just make the methods slightly easier.

[max-sixty]

Ideally we would remove all plotting code from pandas (except for say resampling callback and such). And just defer to various engines.

👍

[Ochirgarid]

Received this issue from CodeTriage. Seems like it is already closed issue @jorisvandenbossche could you explain why you reopened the issue?

[mroeschke]

From the reversion of this feature in #24912 and discussion within, it appears that there's not much appetite in supporting this directly in an accessor and having a free standing function is fine. Closing.