Comment author: neq1 03 November 2010 01:18:30AM 0 points [-]

Who has not experienced the chilling memory of the better things? How it creeps over the spirit of one's current dreams! Like the specter at the banquet it stands, its substanceless eyes viewing with a sad philosophy the make-shift feast.

-Theodore Dreiser, The Titan

Comment author: wedrifid 28 October 2010 06:02:15AM 12 points [-]

Wow, I just read Robin's writeup on this and it caused me to significantly lower the amount of credence I place on his other positions (but very slightly lower my opinion of supplements). It just struck me as overwhelmingly sloppy and rhetorical. Particularly his justification attempt in response to this thread. (But I suppose Robin's responses to criticism have never impressed me anyway.)

Comment author: neq1 28 October 2010 02:17:16PM 2 points [-]

If you look at Table 2 in the paper, it shows doses of each vitamin for every study that is considered low risk for bias. I count 9 studies that have vitamin A <10,000 IU and vitamin E <300 IU, which is what PhilGoetz said are good dosage levels.

The point estimates from those 9 studies (see figure 2) are: 2.88, 0.18, 3.3, 2.11, 1.05, 1.02, 0.78, 0.87, 1.99. (<1 favors supplements, >1 favors control)

Based on this quick look at the studies, I don't see any reason to believe that a "hockey stick" model will show a benefit of supplements at lower dose levels.

Comment author: neq1 24 September 2010 12:00:34AM 5 points [-]

It would be nice if the top scoring all-time posts really reflected their impact. Right now there is some bias towards newer posts. Plus, Eliezer's sequences appeared at OB first, which greatly reduced LW upvotes.

Possible solution: every time a post is linked to from a new post, it gets an automatic upvote (perhaps we don't count it if linked to by same author). I don't know if it's technically feasible

Comment author: datadataeverywhere 23 September 2010 12:43:22AM 1 point [-]

I suppose what I was getting at was asking whether it is something that you have enough interest in or ideas about that you would like to collaborate on.

Comment author: neq1 23 September 2010 12:51:05AM 0 points [-]

I'd be glad to discuss it.

Comment author: Douglas_Knight 22 September 2010 06:30:08PM 4 points [-]

Rather tangentially...
Here is a linguistic danger of your article. It's not much of a danger if one reads the text in order, but if one starts with headlines, "How common are coding errors in research?" could be confusing because many fields of research (probably most researchers) use "coding" to mean "labeling." eg, when a human watches a tape of a monkey and codes it as "looked left" or "looked right." And they keep track of rates of "coding errors."
So I'd suggest changing that headline to "programming."

Comment author: neq1 23 September 2010 12:30:45AM 0 points [-]

good point

Comment author: datadataeverywhere 23 September 2010 12:18:18AM 3 points [-]

I know of no such study, and have failed to find one in a quick literature search.

I occasionally run behavioral psych studies, and this seems like a good candidate. How would you feel about me adapting this into a study?

Comment author: neq1 23 September 2010 12:23:23AM 0 points [-]

That would be great. I'd love to see the results.

Comment author: neq1 22 September 2010 11:31:39PM 9 points [-]

In the first example, you couldn't play unless you had at least 100M dollars of assets. Why would someone with that much money risk 100M to win a measly 100K, when the expected payoff is so bad?

Comment author: Morendil 22 September 2010 08:02:21AM 11 points [-]

I would not be surprised if at least 20% of published studies include results that were affected by at least one coding error.

My intuition is that this underestimates the occurrence, depending on the field. Let us define:

  • CE = study has been affected by at least one coding error
  • SP = study relies on a significant (>500 LOC) amount of custom programming

Then I'd assign over 80% to P(CE|SP).

My mom is a semi-retired neuroscientist, she's been telling me recently how appalled she's been with how many researchers around her are abusing standard stats packages in egregious ways. The trouble is that scientists have access to powerful software packages for data analysis but they often lack understanding of the concepts deployed in the packages, and consequently make absurd mistakes.

"Shooting yourself in the foot" is the occupational disease of programmers, and this applies even to non-career programmers, people who program as a secondary requirement of their job and may not even have any awareness that what they're doing is programming.

Comment author: neq1 22 September 2010 10:56:01AM 3 points [-]

In cases where a scientist is using a software package that they are uncomfortable with, I think output basically serves as the only error checking. First, they copy some sample code and try to adapt it to their data (while not really understanding what the program does). Then, they run the software. If the results are about what they expected, they think "well, we most have done it right." If the results are different than they expected, they might try a few more times and eventually get someone involved who knows what they are doing.

Comment author: CronoDAS 22 September 2010 03:27:21AM 29 points [-]

Feynman once talked about this specific issue during a larger speech:

We have learned a lot from experience about how to handle some of the ways we fool ourselves. One example: Millikan measured the charge on an electron by an experiment with falling oil drops, and got an answer which we now know not to be quite right. It's a little bit off, because he had the incorrect value for the viscosity of air. It's interesting to look at the history of measurements of the charge of the electron, after Millikan. If you plot them as a function of time, you find that one is a little bigger than Millikan's, and the next one's a little bit bigger than that, and the next one's a little bit bigger than that, until finally they settle down to a number which is higher.

Why didn't they discover that the new number was higher right away? It's a thing that scientists are ashamed of--this history--because it's apparent that people did things like this: When they got a number that was too high above Millikan's, they thought something must be wrong--and they would look for and find a reason why something might be wrong. When they got a number closer to Millikan's value they didn't look so hard. And so they eliminated the numbers that were too far off, and did other things like that. We've learned those tricks nowadays, and now we don't have that kind of a disease.

Comment author: neq1 22 September 2010 03:33:37AM 1 point [-]

Good find. Thanks.

Error detection bias in research

54 neq1 22 September 2010 03:00AM

I have had the following situation happen several times during my research career:  I write code to analyze data; there is some expectation about what the results will be; after running the program, the results are not what was expected; I go back and carefully check the code to make sure there are no errors; sometimes I find an error

No matter how careful you are when it comes to writing computer code, I think you are more likely to find a mistake if you think there is one.  Unexpected results lead one to suspect a coding error more than expected results do.

In general, researchers usually do have general expectations about what they will find (e.g., the drug will not increase risk of the disease; the toxin will not decrease risk of cancer).

Consider the following graphic:

Here, the green region is consistent with what our expectations are.  For example, if we expect a relative risk (RR) of about 1.5, we might not be too surprised if the estimated RR is between (e.g.) 0.9 and 2.0.  Anything above 2.0 or below 0.9 might make us highly suspicious of an error -- that's the red region.  Estimates in the red region are likely to trigger serious coding error investigation.  Obviously, if there is no coding error then the paper will get submitted with the surprising results.

continue reading »

View more: Prev | Next