save manual rotation as dataframe of angles for factor pairs

[maxheld83]

as an alternative and/or improvement to manual rotation as per #97 @bobbraswell suggested the below in an Email:

As for the best way to track and reproduce manual rotation, I have an alternative to suggest (you don't need to change if what you have is working, but it seems complex and difficult to debug if inconsistencies emerge in reproducing rotations). The alternative begins by setting a practical limit at 7 as the number of factors anyone will try to rotate manually. This means we can number in advance the 21 (n(n-1)/2) pairs of factors that can be rotated with respect to each other. This leads to a data structure in the form of a matrix with 21 rows, where each row is associated with a specific pair of factors, and each column is a record of what the user did with that pair. That is, for each hand rotation, a column is added to this matrix, with the degrees of rotation in the appropriate cell and zeros in the others. This would allow the exact sequence of rotations to be reproduced by taking input from this matrix instead of from the readline function.

I'm just keeping a record of this suggestion here.

[maxheld83]

I would be a little bit skeptical about this suggestion based on my experience with q.mrot.do and q.mrot.choose, though I may have misunderstood @bobbraswell's above suggestion.

Two reasons for my skepticism:

• a design that limits us to a specific number of factors seems to me to be a somewhat arbitrary limitation, that might later cause us problems (though, admittedly, 7 factors seems very generous for every conceivable study)
• more importantly, I believe recording angles of rotations (rather than the completed rot.mat as q.mrot.choose does), falls short of reproducibility and includes additional complications. Crucially, any list of angles would only be meaningful, if we also know the order in which these angles where applied, and we would have to prevent users from going back and forth between different factor pairs, because rotations (and their underlying matrix multiplication) are not commutative, meaning, the order matters. An example: if a user first rotates factors 2/3, and then 1/2, that is not the same, as applying the recorded angle to 1/2 first, and then the recorded angle of 2/3. To make matters worse, users could not go back and forth between the different factor pairs, as they might plausibly want to. I previously ran into this problem in #185

As I said, maybe I am misunderstanding the original proposal, but these would be the concerns that originally led me to adopt a rot.mat approach.

[bobbraswell]

Max, I think you may not have understood the suggestion, but it was my fault for making it more complex than necessary. Let me start again.

Imagine a stenographer watching over the shoulder of a researcher doing manual rotation. The researcher takes any pair of factors in any order, for as many steps as he deems necessary, but his actions are completely reproducible so long as the stenographer captures a 3-tuple of information for each step and captures these 3-tuples in correct sequence. The information needed (besides the sequence) is X axis factor, Y axis factor, and degrees of rotation.

The stenographer doesn't have to know or care about the contents of any matrix at any stage, so long as the key information about what is done to which factors in what order is recorded.

What you are doing now by saving a resulting rotation matrix can be reproduced by machine if the researcher wants to reproduce the final result but doesn't care about seeing or understanding the stages passed through along the way. Thus it may be useful for reproducing a rotation but not very useful for teaching manual rotation. And if there is a bug, it may be very hard to detect or squash it.

What I'm proposing can be reproduced either by machine or by hand (e.g., using PQMethod), can be stepped through for the purpose of learning hand rotation, maps directly to the researcher actions taken during the rotation process, and is less likely to present any debugging challenges since it is extremely simple.

Please ignore the earlier suggestion and consider this correction/simplification. In my earlier suggestion I thought it might simplify things to number the 21 possible pairs of factors for the first 7 factors (and put it all in a big matrix that could be manipulated using matrix algebra), but it was more complex than necessary and brought us up against the first of your two reasons for skepticism. Your second reason for skepticism is not relevant to either version of this suggestion since both are just data structures to save all the steps in whatever order they occur.

Example: If a person rotated F1 against F2 40 degrees clockwise, followed by F2 against F3 10 degrees counterclockwise, followed by F1 against F2 3 additional degrees clockwise, the data structure resulting from the "stenography" would be

1 2 -40 2 3 10 1 2 -3

If for some reason we don't want negatives, we can list it as:

1 2 320 2 3 10 1 2 357

(where -40 degrees is recorded as 360 - 40 = 320)

This structure could have as many additional rows as needed. A manual rotation that involved 8 factors and 100 steps would produce a matrix of three columns by 100 rows. By taking this structure as input instead of getting input interactively from the user, the rotation can be precisely machine-replicated. By printing out the structure, it can be hand-replicated.

I hope this is clear.

[maxheld83]

Yes, thank you very much – I really did misunderstand your original suggestion, apologies for my premature skepticism.

I agree that such a complete "instruction list" would be informative, and I had initially toyed with that idea, too – might be worthwhile to see a function that works like that! (I'm not sure how this could be worked into the existing q.mrot.choose, but maybe that would be possible too.

One concern I'd have is that two different instruction sets might actually arrive at the same result, and it wouldn't be immediately obvious from the instruction set – but maybe that is very much your point @bobbraswell ?

Anyway, I'm just adding my thoughts here, hoping they are helpful – not at all implying what should or should not be done, or what might be worthwhile for Q methodologists.

[maxheld83]

I do think that my existing functions q.mrot.choose and especially q.mrot.do are quite robust, and not very prone to bugs :smile: Whether q.mrot.do does what it is supposed to do can be easily validated by passing it some manually retrieved varimax rotation matrix (that is in fact now an automatic test run on every build as per #89).

q.mrot.choose has also been validated against PQMethod in #256 – and it checks out on a number of scenarios (same results).

In general, q.mrot.choose quite simply matrix-multiplies the currently entered angle to the existing rot.mat and carries that over time, so it's not terribly complicated.

There's also the added security that users get immediate visual feedback, and that feedback can – by definition – always be recreated used by the currently used rot.mat.