-
Notifications
You must be signed in to change notification settings - Fork 7
Description
Thanks for the great package.
I recently had an idea for an alternative beeswarm algorithm, and I thought I'd share it here in case it's something that might be useful to include in the beeswarm package. Equally, my approach might be a terrible idea for some reason and I'd love to receive feedback if so! :-) Also copying in @eclarke, @sherrillmix and @csdaw because of your work on ggbeeswarm{,2}.
The idea is that we don't decide in advance the order in which points will be placed. Rather, the algorithm decides on each iteration which single point to place next. It does this by choosing a point that can be placed as close as possible to the non-data axis without overlapping any point that has been placed so far. Ties are broken by priority (e.g. "ascending").
The following two examples use priority="ascending". The first uses the new "compactswarm" method; the second uses the existing "swarm" method.
The following two examples use priority="random". Again, it is the new method followed by the existing one.
To my eye, the new method often creates a tidier-looking plot, and it tends to require less horizontal space (if the data axis is vertical). A downside is that my current R implementation at https://github.com/jtrim-ons/beeswarm is slower than the "swarm" method (perhaps ~5 times slower if there are 2000 data points).
I also have a faster JS implementation at https://github.com/jtrim-ons/accurate-beeswarm-plot.
I'd be happy to open a PR if any of this is helpful.



