coordinate ordr with new ggbiplot

[friendly]

Last summer, I took over maintenance of the ggbiplot package, originally by Vincent Yu. Source is at https://github.com/friendly/ggbiplot and docs at https://friendly.github.io/ggbiplot/
I did this because I'm writing a book and wanted a reasonably robust ggplot version to use for examples. I also attended the CARME 2023 Conference in Bonn and spoke with some leading developers of biplot methodology about the desire to standardize efforts in a comprehensive pkg within the ggplot framework. Some notes on this discussion: https://github.com/friendly/ggbiplot/blob/master/discussion/biplot-packages.html

I see that you have fully developed what was on the experimental branch and made it much more robust and versatile.
On the other hand, it is somewhat more complicated to use (at least so far for me) and suffers by being less visible in the ordr package.

Perhaps there is someway to merge your efforts with mine into an ordr-flavored ggbiplot package?

[corybrunson]

Hi @friendly ! Thank you so much for raising the issue. I noticed a month or two ago that you had taken over {ggbiplot} but i have not had time to give it a close look.

The CARME 2023 notes include much of what also motivated me to put {ordr} together. It was for my own use for a while, but Joyce Robbins got me to start taking it more seriously as a tool for other users, and the slideshow linked in the README is my best articulation of how it's designed. (Also, i had not been aware of {biplotEZ}! It's great to know that i no longer have to rely on a loading {UBbipl} locally.)

I have a few thoughts about this, but i'm sure you do too, so it might make more sense to talk through them in real time.

1. Are there markets both (a) for many-parameter single functions like those provided by {UBbipl} and {ggbiplot} and (b) for layered collections like those provided by {ordr} (inspired by {tidygraph} and {ggraph})? My sense is that there are, so that both options should be available. autoplot() sort of fits the former description, but {ggbiplot} does way too much to build into an autoplot() method for 'prcomp', 'lda', etc. objects.
2. What trade-offs are imposed by the desiderata raised by CARME participants? My sense is that making the package low-level would introduce a lot of tension with making it Tidyverse-integrable.
3. My plan for a while now has been to spin off a few packages from {ordr}: (i) a low-level package that provides the accessor methods and some base R printing and plotting; (ii) a {ggplot2} extension for new geometric layers like StatSpantree, GeomAxis, and GeomVector; and (iii) {ordr.extra} (installable but not on CRAN) to extend methods to lots more classes. Then {ordr} could just provide the Tidyverse integration. Maybe instead {ordr} could provide Tidyverse-except-{ggplot2} integration while {ggbiplot} provides {ggplot2} integration—both single-function options and layer functions?

I'd be psyched to collaborate on this.

[friendly]

Hi @corybrunson
Thanks so much for your detailed reply. I do understand the tensions and trade-offs. For my current use case, I was focused on biplot methods for quantitative data, PCA/LDA based. But wearing a different hat, I also made wide use of biplot-related methods for categorical data (CA, MCA) in my book, Discrete Data Analysis with R, website: http://ddar.datavis.ca/

I didn't mention FactoMineR (with factoextra) and the suite of ade packages in the discussion. These both take a wide view of a collection of reduced-rank/ordination methods, but offer them within a context that adopts its own world-view for how they relate to each other and how one gets graphics to display the results.

Your point (1), "markets" for many-parameter single functions like those provided by {UBbipl} and {ggbiplot} and (b) for layered collections like those provided by {ordr} nails the essential trade-off, and among competitors. I like the idea that there is room for both, perhaps with a simple autoplot(), to which one can add graphic features via calls to stat_ / geom_ functions.

That puts the emphasis on the analysis object, for which there would be presumably autoplot.c;lass methods. Semantically, this is different from a generic biplot() or ggbiplot() suite of methods, that puts the emphasis on biplot.

I like what I can see of the design, just from exploring the docs and source code. I'll have to play with it a bit to get a better sense of usability in my context. As I said earlier, your nice developments in this area might suffer low visibility simply by being named ordr; "ordination" is not something everyone in the potential usage community understands instinctively.

Here's one suggestion: Let's use this issue as a forum that a few other biplot-family folks can participate in. I'm thinking principally of Stephane Drey of the ade packages, Sugnet Lubbe of biplotEZ and Michael Greenacre of all things PCA/CA/MCA

[corybrunson]

@friendly i'd be honored to host a discussion here! Please feel free to tag in anyone you feel should contribute. In anticipation of their comments, i'll refrain from responding in great detail.

Though could you expand on the difference in emphasis between (a) autoplot() class methods and (b) biplot() and ggbiplot() class methods? I'm very interested in how classes should be handled, since my solution—low-level accessors being the only generics with methods for each model class—required me to adjust what i think of as "elegant".

As to the package name, i could not pass up the opportunity to play on broader R package naming conventions and the notion of "tidy" data/models at the same time. : )

[corybrunson]

@friendly FYI i'll present on {ordr} and its future directions to the ggplot2 extenders next month (Nov 13 @ 14:00 ET).

1. If you have the time slot free, you and other biplot colleagues would be very welcome to join! I can forward the Zoom link or you can contact Gina Reynolds for it.
2. I expect the club would also be interested to hear about how you've overhauled {ggbiplot}, and any other thoughts on extending {ggplot2}, at a future meeting.