Re: New plot capability: "bee swarm" plots

[Tait <gnu...@t4...>]

>   http://www.jmp.com/support/help/images/students.gif
> ...
> I found those random jitter plots to be ugly so I never pursued it.
> I find the beeswarm plots to be much nicer visually and they also
> convey more information.  ...

Random jitter may not be very pretty, but within the bounds of what
it's meant to do, it doesn't distort the data. In the limit of
enough data points, a random jitter would also approach a 2-D
boxplot or "violin" plot. Pretty graphs are nice, but the plotting
tool should not encourage them at the expense of accuracy.

> > Jitter means applying a "small" (definition of which is open to
> > debate) offset to the specified dimension of a data set. I have
> > implemented it before within the "... using ..." directive to plot,
> > and that is where I believe it makes the most sense, e.g.
> >     plot 'data.dat' using (jitter($1)):2
> > As used this way, the jitter offsets don't alter the non-jittered
> > dimension, which the R examples appear to do.
> 
> That confused me at first also, but it turns out that the visual
> appearance of the "bee swarm" plots is a result of applying a pure
> x displacement sequentially to points that have been sorted on y.
> The jitter is applied only to points that would otherwise overlap.
> Since successive points have a larger sorted y value
> and also receive a larger +/- x displacement, you get the
> upward-sweeping lines of points that are so distinctive.

This does not appear to be what's happening in the "method=swarm"
plot from the R package, at least. There are points where the
greater x-displacement point's y-coordinate clearly overlaps with
another point who's x-displacement puts it on or nearer to the
central x-axis. There seems to be some chunking function applied to
the points before they're sorted, and this distorts the data in a
way similar to how histogram binning distorts data. (The solution to
that distortion is to use kernel density plots instead, and for the
same reason, I'd take a density contour plot* or a heat map any day
in preference to a beeswarm plot.)

* gnuplot doesn't have very good support for density plots or any
sort of plot that requires an aggregate view of the input data. Some
of this is done via the "smooth" options, but it's limited.

> The opposite is true for the "square" option.  Although at first
> glance it looks like this results from applying no displacement on y,
> in fact the only reason the displaced points line up in horizontal
> layers is that a y displacement is added to remove the incremental y
> from successive overlapping points.

The R "square" and "hex" methods are probably the clearest examples
of what not to do, namely grid the data and draw points onto the
grid. As you note, this does produce pretty-looking plots and I'm
not averse to having such a feature in gnuplot, but it should be
named in accordance to what it is -- resampling the data (ala
dgrid3d), not "jitter".

> > The extension to higher-dimension plots seems straightforward. One
> > might jitter in x AND y, or in u and t,
> 
> Sure. I was just wondering if anyone had an example of real-world
> data that would benefit from this form of display. ...

Anything that you do in 1D, someone might do in 2D. So the first
example that comes to mind is any sort of location-based incidence
data. Rainfall is an easily-understood example. Each collection
station has its own x and y location, and reports the amount of
water collected. A map of collection stations with "at least N"
rainfall could be represented as points on an xy plane, and if the
density of such collection stations were high enough for the desired
zoom level, it might be represented using jitter in both x and y.

A highly directional receiver antenna array might sweep around a
360-degree circle, saving a record of some relevant signal received,
each record having "longitude" of the antenna array's angular
position as it rotates, and a "lattitude" corresponding to one of
the N lobes in the array. A plot of record count vs. direction would
tend to draw multiple points on top of each other, and this jitter
in both lattitude and longitude might be desirable to better show
number of records.

I'm the wrong person to defend use of jitter plots, because in these
examples (and any other I can imagine), there's at least one other
way to plot the data that is more clear and more accurate  And were
I the presenter, I'd be using those other plots, not jitter. Even
supposing I couldn't find a better plot type, I'd still prefer to
plot the points -- without jitter -- using partial transparency, so
that as the points/lines stack the color becomes more intense,
thereby showing density through color saturation without needing to
introduce artificial jitter. And indeed, I frequently use the
partial transparency approach when doing exploratory scatter plots.

> >or jitter the size and/or color with "ps variable" or "lc variable".
> 
> When would that ever be useful?
> Spatial jitter removes  overlap so that you can see how many
> points there are. What would perturbing the color or size accomplish?

I am not sure jitter in color would really be useful, since the
peturbation would almost certainly be too small for a person to
usefully distinguish. I just threw it in for the sake of
completeness. But jitter in point size would definitely be useful.
The variable pointsize demo that's already online (using world.cor)
is case in point. If the data were real and discrete, rather than
"(5.*rand(0))", it would be necessary to jitter the pointsize to
distinguish one point from another.