You should not merge master into your working branch, but re-base your branch onto current master. Please remove the merge commit and rebase your commit.

This needs another rebase and to have a few remaining comments addressed.

@mgoacolou I have re-milestoned this as 1.5.x as this needs a re-base and we have not heard from you in a few months. If you can get this re-based and fixed up in the near future we can get it in to 1.4.0.

I'm testing my rebase

one of the image tests seems to be consistently failing

======================================================================FAIL: matplotlib.tests.test_transforms.test_pre_transform_plotting.test----------------------------------------------------------------------Traceback (most recent call last):File "/home/travis/virtualenv/python2.7/local/lib/python2.7/site-packages/nose/case.py", line 197, in runTestself.test(*self.arg)File "/home/travis/virtualenv/python2.7/local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", line 50, in failerresult = f(*args, **kwargs)File "/home/travis/virtualenv/python2.7/local/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-linux-x86_64.egg/matplotlib/testing/decorators.py", line 201, in do_test'(RMS %(rms).3f)'%err)ImageComparisonFailure: images not close: /home/travis/build/matplotlib/tmp_test_dir/result_images/test_transforms/pre_transform_data.png vs. /home/travis/build/matplotlib/tmp_test_dir/result_images/test_transforms/pre_transform_data-expected.png (RMS 20.345)

I corrected the bug in computation of scale. The figure (expected and generated) are close but have not the same x/y limites. Is there a way to know why?

@mgoacolou any interest in continuing to work on this?

RegularPolyCollection already has arotation param. Probably should be consistent with that naming.

@tacaswell Hi, I am now more confident with git now. I'll take a look this week on this.

oh nice, definitely looking forward to this?

so am i correct that after this is in, i can e.g. do:

df=pd.DataFrame({X: ...,Y: ...,C: ['Foo','Bar', ...]})marker_map= {'Foo':'o','Bar':'x'}plot(df.X,df.Y,marker=[marker_map[c]forcindf.C])

No, this is the other meaning of rotate as in 'change the orientation of the marker'. Basically quiver, but with any marker not just arrows.

There are deep performance related issue thatplot has exactly one marker. I would do what you want as

fork,_dfindf.group_by('C'):ax.plot(_df,X,_df.Y,**style_map[k])

is there a more ggplot-like interface to matplotlib? i.e. where you give a DataFrame and column names tox,y,marker,c, and so on and it does _the right thing_™ (including legends)?

seaborn just has its own high-level plots, and pandas’ DataFrame.plot only allows specifying x and y in this way.

i basically want to do:scatter('Height', 'Weight', c='Age', marker='Gender'), and it uses the color cycle for categorical variables and the colormap for continuous ones, plots legend(s) and colorbar(s) and presto!

We are working towards supporting a more robust API like that. You can get
partly there right now by passing the dataframe as the "data" argument and
use the string names for the x and y arguments. I don't think we support
the color and marker arguments yet, though.

On Wed, Mar 23, 2016 at 10:10 AM, Philipp A.notifications@github.com
wrote:

is there a more ggplot-like interface to matplotlib? i.e. where you give a
DataFram and column names to x, y, marker, c, and so on and it does _the
right thing_™ (including legends)?

seaborn just has its own high-level plots, and pandas’ DataFrame.plot only
allows specifying x and y in this way.

i basically want to do: scatter('Height', 'Weight', c='Age',
marker='Gender'), and it uses the color cycle for categorical variables
and the colormap for continuous ones.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#2478 (comment)

currently, mpl works on a “series-based” level, which imho makes no sense for multidimensional data: you can have one dimension represented by shape, the other by color, the third by size, and two more by x/y position. this results in an exponential number of series.

therefore to make sense, your API must deviate from the previous model, and simply track 1. each point individually and 2. each represented feature via legend (marker shape, discrete color), colorbar (continuous color), “volume slider triangle” or axis label (x/y position).

like this, but using anisosceles trapezoid as “colorbar for size”:

color and size should work with scatter +data, but not marker.

The pandas/table/dataframe/R view of data is not universal or fundamental where as vectors / arrays of number are, hence that is what the core of mpl targets and will continue to target.

There is definitely interest from many parties for there to a pandas-aware domain-specific plotting library that lives under the matplotlib gh umbrella organization thatcan require pandas and do these 'magic' things. The only hold up is developer time.@flying-sheep You have any interest in leading this effort?

That said,scatter creates aPathCollection and itshould be pretty easy to extend it to take a vector of shapes instead of broadcasting a single shape.

i don’t know if i’m suited, but i’d definitely like to chime in wherever discussion is happening regarding thedata= API. (where does it happen? could you give me a link?)

regarding an universal interface, i disagree: thegrammar of graphics is a deconstruction/analysis of the way data visualization happens. and those rulesdo directly translate into a data frame structure: a heterogeneous collection of feature columns that each carry one entry for each sample.

by mapping those feature columns onto graphical features, we get all possible permutations of visualizations. so basically, we have to (implicitly or explicitly) reshape our data into this structure anyway when visualizing it, so we might as well use an interface optimized for this shape (pandas.DataFrame)

Thedata kwarg API shipped with v1.5.0.

ah, OK, so this ship has sailed then. damn.

i submitted#6214 for further discussion

I am not sure what you mean by "this ship has sailed". All we implemented
was a generic way toaccess data within a dataframe or other similar
objects, and a minimal usage. I don't see any limitations to extending the
syntax, but that'll have to be done judiciously, like how this first round
of the API was done. There are a few technical improvements that will be
needed (having multiple norms, be able to modify more properties, etc), but
we have been wanting to implement them for awhile now.

On Wed, Mar 23, 2016 at 12:27 PM, Philipp A.notifications@github.com
wrote:

ah, OK, so this ship has sailed then. damn.

i submitted#6214#6214
for further discussion

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#2478 (comment)

... I'm going to close this as abandoned. I'm also not aware that anyone has asked for this functionality for quite a while, and while it looks cool its a significant complication to the code... Feel free to re-open or ask to have it re-opened if I'm closing in error.