Skip to content

[Doc]: More plot types? #23204

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
oscargus opened this issue Jun 5, 2022 · 13 comments
Open

[Doc]: More plot types? #23204

oscargus opened this issue Jun 5, 2022 · 13 comments

Comments

@oscargus
Copy link
Member

oscargus commented Jun 5, 2022

Documentation Link

https://matplotlib.org/stable/plot_types/index.html

Problem

Most of the plot types are shown here, although not all. I guess it is really a good starting point for a newcomer, but also useful for a more experienced person to see what is possible "out of the box".

I wasn't even aware of the magnitude_spectrum etc, but was originally opening for psd/csd.

Suggested improvement

Should there be a section for "Signal processing plots"? Related: #22920 so maybe not all if we are deprecating mlab (but the plots that relies on numpy can stay?).

stairs should be added to basic plot types.

semilog*, loglog? (Good for a newcomer if nothing else.)

@timhoffm
Copy link
Member

  • signal processing plots: rather not. We wouldn't take up these plot types nowadays. What would be useful is collecting the signal processing plots in the examples into their own category.
  • stairs: yes! And likely remove step. step has a very peculiar semantic which most people don't actually want/need. So let's not advertise step anymore.
  • logs: maybe. They are convenient shortcuts for the right task, but a bit awkward conceptually.

@jklymak
Copy link
Member

jklymak commented Jun 10, 2022

I'm pretty defensive about adding new plot types here. This isn't meant to be a comprehensive, or a redo of the Examples page. It's inspired by the cheat sheet, which for obvious reasons cannot contain everything.

@story645
Copy link
Member

story645 commented Jun 10, 2022

Can we add a second page for the less common chart types? the signal processing and {ax}{h,v}{line{s},span} and the like? It gets linked to off plot type, so not fully discoverable but more easily findable than trawling through the gallery? And can act as another way to index into the gallery - sprint season is coming up and cross references are a good sprint activity

@jklymak
Copy link
Member

jklymak commented Jun 11, 2022

My vote is still No. We aren't going to get out of the messy gallery problem by adding more galleries.

@oscargus
Copy link
Member Author

Regarding signal processing, I'd inclined towards deprecating mlab (been trying to move those with history to the very drafty https://github.com/oscargus/mplsignal but to no avail so far).

But isn't having a single overview of available plot types actually counteracting the messiness? Providing a single overview, listed as the first item in the top meny.

To me these are somehow two different things.

  1. I want to see which (conceptual) plot types that are supported out of the box -> Plot types
  2. I want to see how I can do some rather specific tweak to a plot -> Examples

2 will almost out of necessity be messy (although one can of course try to structure it). But adding a few more to the basic plot types will only be helpful (how many are we talking about?). One may even argue that the plot types right now are more aiming at showing off fancy features (which we without doubt should be proud of), but will not really help a user (without Matlab experience) to figure out that loglog is an easy way to get what they are looking for (more likely than them needing tricountourf).

@jklymak
Copy link
Member

jklymak commented Jun 11, 2022

(how many are we talking about?)

I don't know, but I'm pretty opposed to it being much larger. I actually regret not putting up more a fight against stackplot, which I feel is a very idiosyncratic method to have listed as a basic plot type.

{ax}{h,v}{line{s},span}

This is 8, all of which are basically just annotation methods in my opinion, and all of which are just convenience wrappers around plot or fill_between.

Non linear axes are easily googleable. For instance, "logarithmic plot Matplotlib" gets you to the right demo.

@story645
Copy link
Member

story645 commented Jun 12, 2022

(how many are we talking about?)

there are about 60 distinct plotting methods on axes, as listed in https://matplotlib.org/stable/api/axes_api.html?highlight=axes#plotting, but, like Jody mentioned, a good number are annotation type, various forms of log/semilog, the signal processing methods, and text/table. Plus, there's Sankey, which isn't a method on artist but is a charting type.

I don't know, but I'm pretty opposed to it being much larger. I actually regret not putting up more a fight against stackplot, which I feel is a very idiosyncratic method to have listed as a basic plot type.

To me, fill between fills like the more idiosyncratic choice since to me it feels a bit like an annotation since it is highlighting the area between two charts the user is plotting, while the addition that turns fill_between into stackplot is part of constructing the visualization type (like how pie turns its input into ratios).

all of which are basically just annotation methods in my opinion

What about an 'annotation plotting' tutorial as an alternative to the 'more galleries' specifically for the annotation type plots? I agree w/ @oscargus that conceptual plots are a good scoping for the plot-types listing, and acknowledge that conceptual is an open domain specific debate, but I also do think separately it'd be useful to cluster and highlight all the annotation type plots.

@jklymak
Copy link
Member

jklymak commented Jun 12, 2022

We already have https://matplotlib.org/stable/tutorials/text/annotations.html. Adding to that, and/or movibg it seems reasonable to me

@timhoffm
Copy link
Member

timhoffm commented Jun 12, 2022

We have to define what the purpose of plot types is and from that we can derive what should be in there.

I propose: Plot types should give an overview of the types plots you can do with Matplotlib. It's primarily targeted at new / less experienced users. "Look, These are the fundamental plots you can do with Matplotlib." As such, it is not a complete reference, neither of plot functions nor necessarily of all plot types. But it should provide a comprehensive overview. A criterion could be visual distinction. In that sense log and signal plots are not fundamentally different from what we have. Stackplot is similar to fill_between but IMHO visually different enough because it's more a height profile than an area around a line.

In particular, it's not a visual reference index for our plotting/Axes methods. That's something different but would be really nice as well! Essentially https://matplotlib.org/devdocs/api/axes_api.html#Basic but with small pictures next to each entry. Maybe that'd be something for sprints.

@jklymak
Copy link
Member

jklymak commented Jun 12, 2022

: Plot types should give an overview of the types plots you can do with Matplotlib. It's primarily targeted at new / less experienced users. "Look, These are the fundamental plots you can do with Matplotlib." As such, it is not a complete reference, neither of plot functions nor necessarily of all plot types. But it should provide a comprehensive overview. A criterion could be visual distinction. In that sense log and signal plots are not fundamentally different from what we have.

I agree with this as the basic idea of why it was brought over from the cheatsheet. Before this page, the only intro to the library was the three plots on the front page, and the pyplot overview in the tutorials. It serves to give folks an at-a-glance overview of what is available, and it is now the front page image rotator.

A comprehensive visual guide or index to all axes methods is an interesting idea. If there are really only 60, 15x4 or 20x3 doesn't seem crazy. If the same simple examples were reproduced as plotted examples for each method, that could really help consistency. Maybe it could even be as a second switchable version of this page, "plot types, basic" and "plot types, comprehensive". Each method should already have an example like this, but maybe would be nice to give them all a unique and consistent style. If we do this, I think the style would have to be less idealized than the current style, because I think it'd need labelling.

@timhoffm
Copy link
Member

timhoffm commented Jun 12, 2022

I'm not thinking of adding another gallery/index (well, yes I agree it would be nice to have a small example for every function but that's still another thing.). Rather, can we amend the current https://matplotlib.org/devdocs/api/axes_api.html by some visual "icons", e.g.

grafik

Some comments:

  • Of course, not every function can necessarily be represented (e.g. relim() would be challenging), but IMHO it would be perfectly fine not to have visuals on all of them.
  • The images can, but do not have to be generated by code. It's an illustration not a code example. I wouldn't even show the code to the end user. - Effectively this means we just embed images that we have previously created one way or the other.
  • To get this, we probably have to do some manual styling in sphinx.

@story645
Copy link
Member

If there are really only 60

that number comes from my abandoned attempt to catalog the plotting artists, which link

& I think little visuals in the API reference could go such a long way towards solving the issue that what Matplotlib calls things isn't what they're called in all domains & that's also what makes it hard to find things

@jklymak
Copy link
Member

jklymak commented Jun 13, 2022

@timhoffm I think that would be a good addition to the API page. Its pretty well TOC'ed, so the extra vertical space is easily navigated around. It would be good if the little image could be replicated in the API entry as well, to tie it all together; but that may be tricky to implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants