vegandevs/vegan

Related to #655 should the wrappers allow partial unconstrained ordination via formula and `Condition()`?

gavinsimpson opened this issue · 5 comments

Right now we have pca(), ca(), and pco() as wrappers to fitting functions rda(), cca() and pco(). These unconstrained ordination wrappers allow arguments to be passed to the fitting function, so partial ordination is possible but only via the matrix-element interface.

Should we turn the wrappers for unconstrained ordination into S3 generics with the currently-implemented functions becoming the default method and then allowing a formula interface of the form y ~ 1 + Condition(x + z)?

I know you can you just use cca() etc for this, but the same argument as the one given in #655 applies.

If we allow this, should we check that the formula only contains 1 (or 0?) and Condition()? so that it really is an unconstrained model? Or should we allow abuse of the wrappers to pass covariates but check the object returned by cca() etc for presence of covariates (constraints) and if present return that object unmodified, so that we only return a "ca" (etc) classed object if the model has no covariates (constraints)?

This is allowed and has been allowed always. It can be written as:

cca(y ~ Condition(x+z), data=...)

The result object will have partial component ($pCCA) and residual component ($CA), but no constrained component ($CCA).

We can do this without explicit term for constraints because ordination models are centred meaning that they have zero-intercept and omitting a term component (like constraints) means just the same as making it return 0-coefficients. Naturally we must take this centring into account in some cases, like you see, for instance, in functions df.residual.cca and hatvalues.rda.

Actually, you can do this also without formula (and this, I think, has always been the case):

cca(dune,  , dune.env) # missing second term (constraints)
cca(dune, Z = dune.env) # explicitely

@jarioksa Yes to all that; but the question at hand was whether to allow the new wrappers to use Condition() via a formula to fit partial CA etc.

@gavinsimpson Fair enough, but I don't see a need for this feature. The stated purpose of the wrapper was to have an educational simple function for basic PCA, CA & PCO. Having partialized PCA, CA & PCO is not such a simple educational case, but rather a special case of RDA, CCA & dbRDA, and could wait till you have advanced to these methods.

BTW, to my surprise, rda(dune ~ 1 + Condition(Management), dune.env) works! But still adding a formula to PCA is something that could wait till advancing to RDA etc. If you open that option, the next ideas is to implement RDA as pca(dune ~ Moisture + Management, dune.env). That would be confusing.

stats::prcomp and stats::princomp do have formula, but that is one-sided formula that is used to select variables for the analysis. It is a different kind of approach, and I think our kind of approach should be left to constrained analysis instead of having an alternative and different formula for PCA.

I think this was settled: no wrapper. Please re-open if you disagree, @gavinsimpson .