Proposal: Grid arrangement by number of plots #8997
Comments
|
I think this is an extremely good idea! attn @jklymak who has been thinking about similar things. |
|
This looks cool. What I'm trying to do is adjust the size of spines to allow tick labels and other axes components fit inside their grid spec. I didn't read what you did here, but my recommendation is that grid arrangement strategies stay abstract from the size of the axes they contain. Ie the gridspecs divide up the figure in whatever logical way they want and the axes layout handles what is inside that logical region. |
|
Yeah, this only sets up a grid and populates it with subplots of equal sizes, it's built on top of the |
|
A somewhat related idea (which is much less automatic) is at scipy there was a poster about a tool takes an SVG created in inkscape (with some meta-data in it) and builds a set of axes laid out according to rectangles in the SVG. A tool to draw boxes on an figure and then create as axes in that space would not be hard to implement. |
|
@tacaswell Should I start by preparing a PR for this? Or is this something that I should make into an MEP? If we start with just the basic idea, I think it can be handled pretty well in one or two PRs, but the open questions I have right now would be:
I don't think I'll have much bandwidth in the way of working on the implementation for a few weeks. Depending on how much you want to be done as part of the first release, it could be more or less time. I'm happy to let someone else take what I've done so far and run with it if interested. |
|
I think a MEP might be better here, but either way will work. The current goal is 2.1 RC by the end of the month, this is too big to get in for that so we have time for 2.2. Maybe put this in it's own module ( Having a top-level generic function that takes in one of these clases would be good, but in general I think out-of-the-box we should have a few simple functions. |
|
Have a look at #1109 for the disucsion on geometry managers. I actually like the name GridStrategy. |
|
Created MEP 30 for discussion. |
|
@tacaswell For the MEP, should I make a thread on the matplotlib-devel mailing list? I looked through the archives for a template and didn't see any MEP discussions for the past year, so I'm not sure if people just haven't been making MEPs or if they are no longer discussed on that list. |
|
Initiating MEP discussions aren't nearly as formal. Don't worry about
templates, just get the ideas down on paper and we'll revise as we go.
…On Sun, Aug 20, 2017 at 1:10 PM, Paul Ganssle ***@***.***> wrote:
@tacaswell <https://github.com/tacaswell> For the MEP, should I make a
thread on the matplotlib-devel mailing list? I looked through the archives
for a template and didn't see any MEP discussions for the past year, so I'm
not sure if people just haven't been making MEPs or if they are no longer
discussed on that list.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8997 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARy-H-B_A-yafmHMPQXZn9A0PuDwQU8ks5saGiUgaJpZM4OuxFM>
.
|
|
Before adding another interface along the lines of Also, there are other aspects to consider. For example, I often want to have the axes to be the same size, no matter if I have n=2 or n=49, so it should be possible to specify subplot size and the figure size is automatically adjusted. Another handy thing would be named axes, something like This is really just one example, there are many other aspects. It's probably a fundamental effort to get a good API here - but there's also much to gain. Is there any central place where all such ideas around working with and arranging mutliple axes are collected and discussed? |
|
@timhoffm Very happy to have someone concerned about these problems as well. I've tried to dive in and offer some solutions, and your feedback here or in the issues noted below is extremely welcome. I agree that there should be an attempt to have one supported/recommended way to lay out elements, and other ways be deprecated or at least not heavily featured in the docs. For instance, if I read the docs right now, I'd think I was going to try and update the docs after #9082 ( I've never been a fan of The geometry managers ( For your use case, I'm not particularly convinced that is a very general thing to want to do that it would become part of the general API. If you know the size of your elements, then making the figure be the right size isn't too hard. Maybe a layout function that said |
|
I would be interested in such a discussion. My |
|
Great to see this discussion. I very much recognize the common usecase @pganssle describes: a variable number of subplots that you just want to plot in a decently legible way, without having to fiddle with rows and columns. I especially often use this in Jupyter notebooks, where I'm iterating fast. I recently came up with this simple solution that just returns an array of def subplots(total, wrap=None, **kwargs):
if wrap is not None:
cols = min(total, wrap)
rows = 1 + (total - 1)//wrap
else:
cols = total
rows = 1
fig, ax = plt.subplots(rows, cols, **kwargs)
return fig, axUsually, I'll also pass |
|
I think this has its own repo now: https://github.com/matplotlib/grid-strategy Closing here, but not to close off discussion; feel free to reopen or have a new discussion. |
|
Ah yeah, thanks @jklymak, forgot that this was still open. There's a whole new issue tracker over there for us to discuss on ;) |
|
DID this idea got executed by now?? |
|
@hemangjoshi37a Yes, there is a third-party package available: https://github.com/matplotlib/grid-strategy |
|
@pganssle Thank you sir for your help... |
I often have the situation where I have some number of plots I'd like to display that may vary, and I don't want to fiddle around with how many rows and how many columns and such. I think it would be good if
matplotlibprovided some way to declare a "grid strategy" (with some built-in strategies to cover most of what people want), such that you could create subplots with something likeplt.subplots_from_strategy(n, grid_strategy=SquareGridStrategy), and you'd getnsubplots arranged in something as close to a square as possible.To demonstrate, I've worked up a basic "squarish" grid strategy that creates a symmetrical pattern alternating between rows of length
xand rows of lengthx-1to create something close to a square. The code is here (though this is just for demo purposes, I'm not particular about how it's actually implemented), and here is a gallery of demo plots. Some basic examples:I figure this is a good start, and the 'squarish' grid strategy could be changed to take an aspect ratio defaulting to 1, so that it tries to keep within +/- 1 on either side of the aspect ratio.
I've also implemented in there a related but separate feature, which is the
get_gridspecfunction, which takes a tuple of lengthnrows, where each element is the number of columns in the given row - so the n=7 plot above is represented by(2, 3, 2). When creating the gridspec, it center-justifies the evenly-spaced plots rather than having subplots of uneven size like you'd normally get withGridSpecFromSubplotSpec(see this related SO question). I'll note that it would be no trouble to add right and left justification options for this. If you'd like I can make a separate issue for discussion of this feature (which I think would be useful even without theGridStrategystuff above, though the way I've framed theGridStrategystuff, I thinkGridStrategyrelies on this).The text was updated successfully, but these errors were encountered: