Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gavinsimpson opened this issue Jun 20, 2024 · 4 comments

Comments

@gavinsimpson
Copy link
Contributor

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)?

@jarioksa
Copy link
Contributor

jarioksa commented Jun 20, 2024

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

@gavinsimpson
Copy link
Contributor Author

@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.

@jarioksa
Copy link
Contributor

jarioksa commented Jun 21, 2024

@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.

@jarioksa
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants