I am calculating Odds ratios with two variables (Location: Rural vs. nonrural & Initiatives: poverty initiatives vs. no poverty initiatives), and one cell has a "0." I read somewhere that you could perform a Haldane-Anscombe correction to produce the odds ratio, but I can't figure out how to do that in SPSS. Does anyone know how to perform this or have an alternative recommendation?
It sounds like you are asking about adding 0.5 to each cell in a 2x2 table, so I was about to suggest that you could read in a dataset with 4 rows with variables for row, column and N (i.e., cell counts with 0.5 added), and then use WEIGHT by N before using CROSSTABS with STATISTICS=RISK to get the OR. But when I tried that, I was very suprised to see that SPSS is rounding the cell counts. Thinking that maybe only CROSSTABS was rounding the cell counts, I tried again with GENLIN (with a binomial error distribution and logit link). But it also appears to be rounding the cell counts--see my code below. I think I'll have to post to one or two SPSS discussion forums to ask if anyone knows why SPSS rounds the cell counts, and whether there is another solution, other than "rolling your own".
Here is the code for my experiments, in case anyone else wants to tinker.
* ===============================================
* File: OR_with_zero_cell.sps
* Date: 20-Jan-2023
* ===============================================.
* Q. Can I use WEIGHT to add 0.5 to each cell count
* before computing the OR via CROSSTABS?
* Some initial attempts suggest that SPSS rounds
* fractional cell counts. Below, I show 4 tables:
* Table 1: Original cell counts
* Table 2: 0.25 added to each cell
* Table 3: 0.5 added to each cell
* Table 4: 1 added to each cell.
NEW FILE.
DATASET CLOSE ALL.
* Suppose 2x2 table cells are: a=10, b=5, c=0, d=6.
DATA LIST LIST /Table row col (3F1) n (F5.1).
BEGIN DATA
1 1 1 10
1 1 2 5
1 2 1 0
1 2 2 6
2 1 1 10.25
2 1 2 5.25
2 2 1 0.25
2 2 2 6.25
3 1 1 10.5
3 1 2 5.5
3 2 1 0.5
3 2 2 6.5
4 1 1 11
4 1 2 6
4 2 1 1
4 2 2 7
END DATA.
WEIGHT BY n.
CROSSTABS row BY col BY table /STAT=RISK.
* As expected, SPSS cannot compute the OR for Table 1
* because c=0. But for Table 2I expected to see OR =
* (10.25*6.25)/(5.25*0.25) = 48.809524. But it seems
* SPSS rounded the cell counts, so treated Table 1
* just like Table 2.
* Likewise, for Table 3, I expected to see OR =
* (10.5*6.5)/(5.5*0.5) = 24.818182. But the OR
* for Table 3 matches the OR for Table 4. This is what
* I would expect if SPSS rounds the cell counts.
* Q. Will GENLIN also round the cell counts?.
SPLIT FILE BY Table.
* Generalized Linear Models.
GENLIN col (REFERENCE=FIRST)
BY row (ORDER=DESCENDING)
/MODEL row INTERCEPT=YES
DISTRIBUTION=BINOMIAL LINK=LOGIT
/CRITERIA METHOD=FISHER(1) SCALE=1 COVB=MODEL
ANALYSISTYPE=3(WALD) CILEVEL=95 CITYPE=WALD LIKELIHOOD=FULL
/MISSING CLASSMISSING=EXCLUDE
/PRINT CPS DESCRIPTIVES MODELINFO FIT SUMMARY
SOLUTION (EXPONENTIATED).
SPLIT FILE OFF.
* A. Yes, GENLIN gives the same OR for Tables 1 and 2,
* and the same OR for Tables 3 and 4.
* ===============================================.
I have posted a question about this to the SPSSX-L mailing list and will post again here if anyone has a nice solution. Meanwhile, you could always do the calculations "by hand" as in the following code. Row 3 shows an example like the one you want, with 0.5 added to each cell count. I included the others for comparison with results from CROSSTABS and GENLIN (see my earlier post).
* Do the calcuations "by hand".
NEW FILE.
DATASET CLOSE ALL.
DATA LIST LIST / a b c d.
BEGIN DATA
10 5 0 6
10.25 5.25 0.25 6.25
10.5 5.5 0.5 6.5
11 6 1 7
END DATA.
COMPUTE ORatio = (a*d)/(b*c).
COMPUTE LogOR = ln(Oratio).
COMPUTE SE = SQRT(1/a + 1/b + 1/c + 1/d).
COMPUTE zcrit = PROBIT(.975).
COMPUTE low = LogOR-zcrit*SE.
COMPUTE up = LogOR+zcrit*SE.
COMPUTE LB = EXP(low).
COMPUTE UB = EXP(up).
COMPUTE zobs = LogOR/SE.
COMPUTE pval = SIG.CHISQ(zobs**2,1).
FORMATS Oratio LB UB zobs pval (F8.4).
LIST a to Oratio LB UB zobs pval.
Output from LIST:
a b c d ORatio LB UB zobs pval
10.00 5.00 .00 6.00 . . . . .
10.25 5.25 .25 6.25 48.8095 .7821 3045.932 1.8435 .0653
10.50 5.50 .50 6.50 24.8182 1.1685 527.1184 2.0598 .0394
11.00 6.00 1.00 7.00 12.8333 1.2619 130.5120 2.1565 .0310
I've already got a response on SPSSX-L. Jon Peck pointed out that one has to use COUNT=ASIS (rather than the default COUNT=ROUND) to get the desired result here. Here is a modified version of the code I posted earlier. You will have to replace my cell counts (plus 0.5) with your own in the DATA LIST command.
NEW FILE.
DATASET CLOSE ALL.
* Suppose 2x2 table cells are: a=10, b=5, c=0, d=6.
DATA LIST LIST /Table row col (3F1) n (F5.1).
BEGIN DATA
1 1 1 10
1 1 2 5
1 2 1 0
1 2 2 6
2 1 1 10.5
2 1 2 5.5
2 2 1 0.5
2 2 2 6.5
END DATA.
* Table 1 has the original cell counts.
* Table 2 has original counts + 0.5.
WEIGHT BY n.
* As per Jon Peck's advice, use COUNT=ASIS.
CROSSTABS row BY col BY table
/COUNT=ASIS /STATISTICS=RISK.
* End of syntax.
HTH.
I tried the latest syntax Bruce Weaver and modified it to fit my data. The output is attached. It looks like the code worked as you suggested. I think the hard part about interpreting these results is that even though one cell had 0, the odds of the event happening in comparison are still not deemed significant. This seems off, but maybe I do not have enough power to detect significance. Do you have any final thoughts? Thank you again for your time.
NEW FILE.
DATASET CLOSE ALL.
* Suppose 2x2 table cells are: a=100, b=342, c=0, d=8.
DATA LIST LIST /Table row col (3F1) n (F5.1).
BEGIN DATA
1 1 1 100
1 1 2 342
1 2 1 0
1 2 2 8
2 1 1 100.5
2 1 2 342.5
2 2 1 0.5
2 2 2 8.5
END DATA.
WEIGHT BY n.
CROSSTABS row BY col BY table
/COUNT=ASIS /STATISTICS=RISK.
First, if I plug those counts (plus 0.5) into my code for "hand calculations", I get the same OR and CI that CROSSTABS is giving you.
a b c d ORatio LB UB
100.50 342.50 .50 8.50 4.9883 .2854 87.1752
And I get z = 1.1010, p = .2709 .
Bear in mind that the SE of ln(OR) is computed as follows:
COMPUTE SE = SQRT(1/a + 1/b + 1/c + 1/d).
In your case, the values of c and d are both relatively small (especially c), so the SE gets inflated. That makes the CI wider and the z-ratio smaller. HTH.
- Badges
- Science topic
- Similar topics
- Computer Science and Engineering
- Programming Languages
- Python