Live data from Hacker News

Plotnine

plotnine.org

51–60 of 83 posts

Re: Plotnine

#51

Plotnine has been great in my usage, but I see violin plots on the front page. Just say no to violin plots. In almost any situation you either want to talk about the actual distribution (in which case plotting the distribution on one side of the line arranged horizontally is significantly superior to plotting it vertically on both sides of the line for some reason as a violin plot does[1]) or you want to talk about t…

Violin plots have an interesting reputation (https://xkcd.com/1967/, https://www.reddit.com/r/labrats/comments/91ex4u/is_it_just_..., https://jabde.com/2022/12/22/banned-violin-plots/).

For showing distributions, I much prefer strip plots (https://seaborn.pydata.org/generated/seaborn.stripplot.html), perhaps with opacity, or swarm plots (https://seaborn.pydata.org/generated/seaborn.swarmplot.html) - no averaging with an unknown kernel, no hiding distributions behind a box plot, and the data is directly visible. We also directly see whether it is based on 5, 100, or many more points.

When using histograms, binning is usually more straightforward than kernels. And in any case, the mirror reflection of a histogram is not needed.

Re: Plotnine

#54
post #15

I have used neither in quite a while now but there is an alternative from jetbrains that i started using because it shares the same ergonomics and had better (?) documentation. https://lets-plot.org/python/

It seems like the major difference between plotnine and lets-plot is that plotnine wraps Matplotlib (and thus works everywhere Matplotlib is available, but doesn't offer much interactivity), while lets-plot is written in Kotlin and seems to provide interactive plots.

Re: Plotnine

#56
Hey! I worked on the plotnine guide (https://plotnine.org/guide/). Always interested to hear what people find hard to understand about plotnine, or what they wish there were more of (e.g. examples, guide pages, api reference docs).

(Both has2k1 and I work for Posit, which supports plotnine work, but authoring its guide was mostly an act of passion for me :)

Re: Plotnine

#57

Plotnine has been great in my usage, but I see violin plots on the front page. Just say no to violin plots. In almost any situation you either want to talk about the actual distribution (in which case plotting the distribution on one side of the line arranged horizontally is significantly superior to plotting it vertically on both sides of the line for some reason as a violin plot does[1]) or you want to talk about t…

The arguments in the video are mostly misdirected, conflations of related but distinct issues, or (hypocritically) just opinions. Here are the unpacked issues as I see it:

1. Whether to summarize data by a handful of summary statistics or a full density. Obviously, some statistics reported in isolation can misrepresent the underlying distribution, but these considerations ultimately depend on what specific point one seeks to make with a plot. There's no reason a priori that visually annotating summaries/quantiles on a distribution plot can't be helpful (quite the contrary).

2. Whether to "smooth the data" (read: perform kernel density estimation). In some sense this is a long-solved problem: there are mathematically grounded methods for estimating the optimal KDE bandwidth (with varying degrees of assumption on the underlying distribution), which are what's used by any serious plotting library. And whether authors adequately describe what they're actually plotting is a separate matter. That said, there are many reasons not to show a KDE over, say, a binned histogram, especially with raw data and/pr small sample sizes, but these are entirely orthogonal to the choice of displaying a KDE as a violin plot versus something else.

3. How to normalize densities. With raw data, you probably want to compare frequencies (a proper pdf). If displaying just a single distribution, there's obviously no reason not to show the density (it's only a trivial rescaling of the axis tick values). When comparing multiple, the decision again depends on the point of the plot. Losing dynamic range for broader densities when compared with narrower ones can be counterproductive. E.g., in Bayesian parameter inference (where the data are MCMC samples), we almost never compute the actual normalization factor, but rather want to compare relative probabilities (i.e., within a single distribution) of different parameter values across different distributions. Of course, nothing forces one normalization over another for violin plots.

All of those are separate (and rectifiable!) issues from the defining characteristics of a violin plot:

1. Distributions displayed vertically rather than horizontally (both being harder to interpret and inappropriately suggestive). We almost exclusively visualize functions plotted vertically across a horizontal coordinate. I think this is the only valid, specific criticism of the common violin style itself, but the fix is of course trivial.

2. Horizontal violin are then only different from a ridge plot by a) not overlapping (which to me is a major improvement over standard ridge plots, but also trivially fixed) and b) being displayed symmetrically. I find it slightly easier to compare relative heights in the symmetric version, especially when comparing many distributions (such that each is relatively narrow). Even if not, the difference is so superficial/trivial that I don't find it worth arguing about.

Beyond this, the video's main argument (repeated every minute) seems to be that "it's bad, it's just bad", but there are only so many ways to make a 5 minute argument fill a 42 minute video. (This style of video is so grating to me.)

Re: Plotnine

#59
post #33

Earlier quoted context omitted.

How `plot(.. + ggsize(700, 300) + ..)` is superior to a keyword parameter `plot(.. , size = (700, 300), ..)`?

Because, in the latter case, you have to declare a function argument for /every possible option/ that you want your graphics API to expose, and you need to do this every time you add a new option. On the other hand, declaring the options through composition means that the API for "plot" remains static, and adding/removing options can be done trivially without an API change. Composition (rather than parameters) is als…

Honestly operator overloading is almost always a bad choice IMO. There are cases (e.g. matrix math) where it's the right choice because of semantic clarity, but the indirection it creates in exchange for readability is costly. It's always obvious when a function is being called, and how to navigate to the implementation, but the same is not true of overloaded operators.

Re: Plotnine

#60
post #33

Earlier quoted context omitted.

Because, in the latter case, you have to declare a function argument for /every possible option/ that you want your graphics API to expose, and you need to do this every time you add a new option. On the other hand, declaring the options through composition means that the API for "plot" remains static, and adding/removing options can be done trivially without an API change. Composition (rather than parameters) is als…

Honestly operator overloading is almost always a bad choice IMO. There are cases (e.g. matrix math) where it's the right choice because of semantic clarity, but the indirection it creates in exchange for readability is costly. It's always obvious when a function is being called, and how to navigate to the implementation, but the same is not true of overloaded operators.

Well, it's like most tools. For this particular use, does it give more than it takes? If so, use it.

Matrix multiplication? Yeah, everybody knows there's a function being called. And, if it was implemented right, the users almost never have to look at the implementation.

Many other possible uses? Nope. Just nope. Not worth it.

Post reply on HN