2
$\begingroup$

I'm working on a review paper and need to collect the means and standard deviations of a given measure (such as a measure of depression) from papers of interest. However, some authors report means and standard deviations for each item on the measure, but do not calculate the overall mean and standard deviation. For example, for a measure with a 1-5 Likert-type response scale, rather than reporting a mean depression score of 2.5, sd = .34, for the whole scale, they'll report: item 1 mean 2.4, sd=.41, item 2 mean 2.5, sd=.38, etc.

1) Can I calculate the scale mean by simply taking the average of the item means?

2) Is it possible to calculate the accompanying scale standard deviation? And if so, how? It's probably not as simple as taking the average of the item standard deviations....

If it isn't possible, I can just contact the authors, but I hate to bother them if the needed stats can be calculated from the provided information.

Any advice would be greatly appreciated! Thank you!

$\endgroup$
  • $\begingroup$ Are you reasonably certain that everyone's scoring the measure the same way? The unweighted mean of all items, I assume? $\endgroup$ – Nick Stauner Apr 19 '14 at 21:23
  • $\begingroup$ Thank you both for responding! Yes, I'm reasonably certain the measures are being scored the same way with the unweighted mean of all items. $\endgroup$ – user30295 Apr 20 '14 at 23:17
  • $\begingroup$ That does seem most likely. It's a common practice (and a bit of a pet peeve of mine, though it's defensible enough). $\endgroup$ – Nick Stauner Apr 20 '14 at 23:59
2
$\begingroup$

If the scale score is an unweighted mean of ratings that we're pretending are numeric (not ordinal, which Likert ratings actually are), then:

  1. Yes, a sample's mean score is equal to the grand mean of the sample's mean ratings across all items. Here's a demonstration in :

    d8a=data.frame(replicate(10,rbinom(100,4,.5)))                    #simulates Likert data
    for(i in 1:100){d8a$score[i]=mean(as.numeric(d8a[i,1:10]))}    #appends unweighted means
    colMeans(d8a)                                                  #means of items and score
    mean(colMeans(d8a)[1:10])                                           #grand mean of items
    colMeans(d8a)[11]==mean(colMeans(d8a)[1:10])                     #usually prints "TRUE"*
    

    *Oddly enough, with set.seed(2), colMeans(d8a)[11]= 1.985, as does mean(colMeans(d8a)[1:10]), but colMeans(d8a)[11]==mean(colMeans(d8a)[1:10]) prints FALSE. Not sure what's up with that. Might have to ask about this on Stack Overflow later.

    If scale scores are produced by other means, such as by factor scoring using weights based on sample covariance, then these won't be equivalent to the unweighted mean of item ratings.

  2. I can't say for sure that there's no way of doing it, but as you suspect, the simple way won't work.

    sd(d8a$score)                                               #standard deviation of score
    x=c();for(i in 1:10){x=append(x,sd(d8a[,i]))};mean(x)  #mean of item standard deviations
    

    The score's $SD$ will be smaller in general as a consequence of regression to the mean.

$\endgroup$
  • 1
    $\begingroup$ No need to ask on StackOverflow, it's a problem common to every computer calculation you've ever done in floating point. You can't expect equality with floating point calculations, even though they're algebraically equal. If that's not something you've come across, you may find this helpful. ?"==" says "For numerical and complex values, remember == and != do not allow [...] for rounding error." $\endgroup$ – Glen_b Apr 20 '14 at 0:42
  • 1
    $\begingroup$ That help suggests using all.equal - which uses a "near equality" test that is usually sufficient. Compare: a=123456789.8765432; b= 123456789.87654321; a==b; all.equal(a,b) --- alternatively, just check for a percentage error that's very small $\endgroup$ – Glen_b Apr 20 '14 at 0:49
  • $\begingroup$ @Glen_b: I was hoping someone would be able to fill in an explanation for that here. I'm happy it was you, because you tend to add plenty of detail where others would just say something like, "It's a common problem with floating point calculations." Thanks! I figured it might be a rounding error issue, but I couldn't get R to put out means with more significant digits than in my answer, so I assumed it wasn't... $\endgroup$ – Nick Stauner Apr 20 '14 at 1:10
  • 1
    $\begingroup$ I can't resist mentioning this -- Kernighan & Plauger famously put it: “Floating point numbers are like piles of sand; every time you move them around, you lose a little sand and pick up a little dirt.”. When taken across many calculations, accumulated error can sometimes become quite problematic (e.g. a stock index being famously out by 44%) $\endgroup$ – Glen_b Apr 20 '14 at 1:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.