r(111) Error While Factor Analyzing QMethodology Data

[Freddie Bauer]

Hi All,

First time poster here. I read through some of the Advice on Posting, but please correct me anywhwere if my etiquette is off.

Basically: I'm analyzing data from a Q Methodology study I've conducted. I have 20 different variables that contain the orders of statements which I had participants sort. An example of this data is here:

 input byte(rank var1 var2 var3 var4 var5 var6 var7 var8 var9 var10 var11 var12 var13 var14 var15 var16 var17 var18 var19 var20)
-4 24 24 24 17 32  9 28 24 24 24 24  2 24 15 18 24 32 15 24 15
-4 32 32 32 32 34 34 32 32 34 32 32 17 32 34 33 32 34 32 32 32
-3 10 14 29  6  9  2  5 17 17  2  9 24 12  5  4  9 24  6  9  3
-3 33 17 30 33 23 18 15 26 19 19 15 32 16 14  9 21 29 24 15 24
-3 34 34 34 34 29 33 18 34 32 33 17 34 22 32 32 25 33 34 34 25
-2  9 16 14 12 14 15 17  6 14  9 16  1  9  3 14  1  6 13  1 16
-2 16 19 19 14 17 19 19 14 16 10 18  4 15  9 15  2  9 16  2 22
-2 17 26 25 16 22 24 25 18 25 14 23 20 25 18 24 15 15 17  3 33
-2 18 29 26 18 33 32 34 33 33 25 33 21 34 33 29 34 19 22  5 34
-1  3  5  6  1  5 12  9  9  2  7  4 14  5  2  2  4 16  2 12  9
-1 14  9  9  5 18 14 22 15  5 15 19 15 13 16 10  6 17 10 13 13
-1 19 12 16 19 21 16 23 16  9 16 29 23 17 19 13  7 18 12 17 17
-1 22 21 27 22 24 22 29 22 18 18 30 29 18 22 19 19 22 14 19 18
-1 25 22 33 25 28 25 33 25 20 34 34 31 29 24 27 33 30 19 22 19
 0  5  3  5  7  2  3  7  3  1  1  2 12  1  1  3  5  1  3 16  4
 0 11 10 15  8 16  4 10 19  3  3  6 16  2  4  6 11  2  9 18  5
 0 12 23 17 10 19 11 11 23 15 12 12 18 14 27 26 17  3 11 25  6
 0 13 27 18 20 20 13 12 28 22 13 14 22 26 28 28 18  4 25 26  7
 0 15 28 22 21 27 17 24 29 26 17 22 25 28 29 31 26  5 29 28 10
 0 20 31 31 24 31 28 30 30 29 31 25 28 30 30 34 27 14 31 33 12
 1  1  1  4  2  1  1  2  2  6  4  1  9  3 12 11  3 10  4  7  2
 1  2  2 10  4  3  7  3  5  7  6  3 13  4 13 16 14 12  7  8 23
 1  6 15 12  9 12 29 16 10 11 22  7 19 19 17 17 16 13 18 10 27
 1  7 18 23 11 15 30 20 12 12 29 13 26 21 20 22 20 25 27 29 28
 1  8 20 28 13 25 31 31 31 21 30 26 27 33 21 23 28 28 33 31 31
 2  4  6  2 15  7  5 13  1 10  5 10  7  6 23  7 13 23  5  6  1
 2 21 13 13 26  8  6 14 20 13 20 11 10 23 25 12 22 26  8 11 26
 2 23 25 20 29 11 10 21 21 23 26 20 30 27 26 20 29 27 23 27 29
 2 28 33 21 30 26 27 27 27 31 28 21 33 31 31 21 30 31 28 30 30
 3 26  4  1 23  4 20  4  4  4  8  5  3  7  6  1  8  7  1  4 14
 3 29  7  3 27  6 21  8  7  8 11 27  5 10 10  8 12 20 26 14 20
 3 30 11  7 28 13 26 26 11 27 21 31  8 20 11 25 23 21 30 20 21
 4 27  8  8  3 10  8  1  8 28 23  8  6  8  7  5 10  8 20 21  8
 4 31 30 11 31 30 23  6 13 30 27 28 11 11  8 30 31 11 21 23 11
end

I'm trying to use

qconvert

, which is a command that converts this data into a format to be factor analyzed. However, every time I run it I get an r(111) errror. I've tried running that command as

qconvert var*, save(file)

as well as

qconvert var1-var20, save(file)

. However, every time I get

ranking not found r(111);

.

Does anyone have an idea of what may be happening here? Are my variable names not formatted correctly? I tried changing around the names, but that still doesn't seem to work. Other functions work just fine with those variable names. For example

sum var*

works just fine.

Any help is appreciated, and please let me know if I can provide other details. I apologize if the formatting for the data example is poor, and I can fix as best as possible.

Thank you very much for taking the time to help!!

-Freddie

[Nick Cox]

qconvert is from SSC.

I don't know anything about this approach, but the help file says this

qconvert coverts the raw Q-sort file into a new Q-sort file which is ready for analysis by qfactor program. The raw data file should include one variable named
"ranking" which shows the rankings based on the Q-sort table from the left (e.g. -4 -4) to the right (e.g. +4 +4). This variable should have the same number of
entries as the number of statements (Q-sample or Q-set). The other variables are raw Q-sorts.

This may be as simple as rank being unacceptable as a variable name; you really must use the name ranking.

[Nick Cox]

That's exactly the problem, so fire up rename ranking rank

/***************************************************************************/
/* THIS PROGRAM READ DATASET ENTERED INTO STATA AND REPLACES STATEMENT */
/* NUMBERS WITH THEIR RANKINGS. */

*! version 1.10 04JUN2019
program define qconvert
version 12.0
syntax varlist(min=2 numeric) [if] [in], SAVe(string)

preserve

qui gen StatNo=_n

foreach var in `varlist' {
confirm variable `var' 
qui gen new`var'=StatNo
local N=_N
forvalues j=1/`N' {
local s=`var'[`j']
qui replace new`var'=ranking[`j'] if StatNo==`s' 
}
}
//
keep StatNo new*
foreach var in `varlist' {
ren new`var' `var'
}
//
save `save'.dta, replace
restore
end

[Freddie Bauer]

Boy oh boy, do I feel silly! That worked perfectly. Thank you very much, Nick. I really appreciate you helping out!

-Freddie

[Nick Cox]

Don't beat yourself up there. Most mistakes look silly once you see what they are: experience mostly means getting quicker at spotting them.

There are various general guidelines here, and I don't always follow them all myself as carefully as I should. Here are some and the nature of the beast implies that this can't be a complete list.

* Read the help. Here it is explicit that one variable should be called ranking.

* Look at the code. Sometimes it will be too complex or too long to follow easily, but it's always worth a look. Here it is clear from the code that the command really does want to see a variable called ranking.

Aside: If the help seems to contradict the code, tend to believe the code. Stata doesn't read the help file to understand what it is or should be doing. It does read the code and try to execute it,

* Debug actively. Staring at the code until you see what is wrong can work, but often you need to set trace on to see where a command fails, and to start getting ideas on why it fails. If a command calls other commands, and perhaps even yet others, you may need to fool around with set tracedepth to avoid getting too much output (or too litte).

* Debug actively (yet more). That can mean adding extra code temporarily to see what is what. Use display or macrolist to see constants, including macros. Use list to see values for key variables in memory. Use summarize or count to check presumptions about variables: If a variable should be constant, does it vary? And vice versa! If a variable should take on certain values, does that happen? Are you being bitten by missing values? Remove capture or quietly if they are just concealing behaviour you need to know about.To avoid too much messing around, fork code: clone your do file or program under a different name, pepper it with extra "show me" code, and abandon it without compunction once it has done its job.

* Reduce the code and the dataset while debugging. Focus on the simplest case for which you know the answer, or at least can imagine what will happen. (Not needed here, but often the most important tip in the book. Sometimes people throw very complicated code at large and complicated datasets, which rarely works well, or at least it rarely works quickly.) Once that works, reintroduce complexity one step at a time.

* Attention to detail makes a good programmer. Some of the simplest bugs are just spelling and punctuation errors, including incorrect names for variables or macros, misplaced commas, unmatched parentheses, or brackets, or braces, or quotation marks. Read the code very slowly indeed. Use the features of good text editors to search the code or to find matches.

* Try to think like Stata. Stata's point of view always takes precedence over what you (or the programmer, if different) thinks it will or should do. This can be hard to do well, even with experience! What does Stata know at this point? How will it interpret this command? Here the question (in hindsight) should be: How does Stata know what the rankings are? Answer: As in the help, it presumes there is a variable called ranking.

* Try to think like the programmer. That is as much simple psychology or sociology as anything else. This can be even harder, but it can be a source of insight. WIth community-contributed commands, there is usually in the first instance a focus on writing what you want yourself, and only later some altruism that leads people to make commands public in the hope that others will find them useful. A frequent stopping rule is to stop coding when the program does what you want, which should not seem surprising or outrageous. At a guess, the programmer of qconvert really needed the flexibility of being able to specify the variable names you have for the main group of variables, but was prepared to let their personal rule that there is a key variable that must be called ranking be the rule for all users (unless they clone and then change the code). A mix of user-specified names and wired-in names is perhaps puzzling and even not very good style. Certainly the command could have been written differently, to allow all variable names to be the user's choice, or to have a default and let users override that default optionally.

(As an occasional programmer myself, I know that the help files of several of my commands carry long lists of thanks to Stata users who found bugs, limitations, and other quirks, and who had good suggestions about extra features. It's not all self-sacrifice by any means: sometimes I am just not interested in extending a command in the way someone else wants or have good intentions that are never implemented.)

[Freddie Bauer]

That is an amazing list of helpful tips!! Seriously, thank you. I haven't coded anything since my undergraduate degree (nor have I dealt with statistical software outside of SPSS). Your tip on looking at the actual code is really helpful. I completely neglected that.

Thanks again! Have a great week.