fix: psych::principal changes order of factors, q.mrot.do does not

[maxheld83]

this is a weird bug that came up in testing (luckily).

psych::principal apparently changes the order of factors in the output upon (automatic) rotation in some cases, as per http://stackoverflow.com/questions/32349235/cannot-reproduce-varimax-rotation-from-psych-order-of-factors-is-changed

This at least causes problems in testing (when testing q.mrot.do against psych::principal), but I am afraid it might cause problems elsewhere, too.

Need to get to the bottom of this.

[maxheld83]

above commit does not actually solve this problem, just avoids it in testing -> suboptimal

[maxheld83]

Ok, it seems to me that we must really solve this problem at a somewhat fundamental level (see suggestions below).

Here's what happens:

• psych – by default – reorders (principal) components according to their Eigenvalues (as is always the case in their raw, unrotated form as principal components)
• this does not always, but sometimes lead to a different loadings matrix

Here's why that matters:

• so far, this will likely not cause dramatic problems in qmethod, though this (undocumented?) behavior may be pretty confusing to users (or then again, maybe not, because rotated components are quite different anyway).
• this does matter for q.mrot.do, because that function also applies (manually provided) rotation matrices, but does not re-order factors (see below for why that doesn't work).
• In general, I find it pretty bad if one rotation function (qmethod(rotation=varimax) does reorder, and the other q.mrot.do does not. That can lead to a lot of confusion.
• now, consider the worst case scenario:
  1. user starts with an already rotated matrix
     • no reason not to, q.mrot.choose can happily do that, and so can q.mrot.do
     • it's also a helpful scenario; you might want to start from varimax, rather than from an unintelligible unrotated state
  2. user happily rotates away
  3. at the end, for reproducibility, the additional rotation matrix from q.mrot.choose is multiplied to the original rotation matrix already in results$brief$rotmat.
     • because: reproducibility!
  4. this raises the expectation (that's the point of reproducibility) that if that new, composite rotation matrix were to be multiplied to unrotated principal (!) components, you'd get the final result again.
  5. but you don't!, because:
     • the additional rotation matrix from q.mrot.choose was created using a reordered loadings matrix, so the angles for 1st, 2nd etc. factor are all out of whack
     • applying the composite rotation matrix to an original unrotated loadings matrix via q.mrot.do does not reorder, so you get different results
  6. result: everyone is terribly confused and results cannot be reproduced.

There are, in principle (principal) (haha), 2 ways out of this:

1. Teach qmethod() (preferably psych::principal) not to reorder, at least optionally, and only accept those results as inputs to q.mrot.choose and q.mrot.do.
2. Teach q.mrot.do to do the same kind of reordering.

I'm in favor of 1., because:

1. rotated principal components are no longer principal components anyway, so there's not a good reason to keep them in any particular order. CrossValidated seems to agree
2. Q methodologists are not that interested in the relative sizes of Eigenvalues to begin with, because non-random sampling, yada, yada yada ... – so we might not care
3. reordering inside of q.mrot.do, which is called by q.mrot.choose would be a UX disaster: while manually rotating, axes would jump around (because order is changed), and plots would be 90° rotated or completely changed.
   • intelligently fixing that might be possible (by forestalling the ordering or something), but at some point, inevitably, the result would have to be reordered, and stuff would suddenly (inexplicably) look very different for the user.
   • either way, I am guessing disorientation would ensue.
4. It's just darn simpler, smaller chance of baaaad bugs.

[maxheld83]

ok, so, if no one has a better idea :smile_cat: I'll go for reverse-engineering the ordering in #273 to fix this issue, until/unless psych::principal makes it optional as per #274