Skip to content
Prev 31172 / 63421 Next

The Quality & Accuracy of R

Muenchen, Robert A (Bob) wrote:
saying thank you all very much for the incredible contribution you have
made to science through your work on R.
managers, directors, CIOs etc. are skeptical of R's quality/accuracy.
And as the recent NY Times article demonstrated, the commercial vendors
rarely miss an opportunity stoke those fears. I have read many r-help
posts on this subject so I was aware that R was developed and tested
with great care, but until I read the clinical trials doc, I was not
aware that they were as many steps and that they were as rigorous (use
of version management software, etc.) Even as I read the document, the
opening paragraphs made me think it was far too focused to be of general
use. Luckily, I kept reading through the CFRs. Modifying that doc would
take little effort as I outlined in my original post (below). Putting it
in easy reach of every R user is important. By adding that to the docs
in R's Help menu, and adding a FAQ entry for it, all R users will have
ready access to it.
would let every R user run the test suite, very clearly showing them
that it is being done. I realize this is a superfluous step, since you
have already run the test suite against R before releasing it. However,
it would provide user assurance that they could easily demonstrate to
skeptics that very thorough testing is being done. I don't know whether
written messages that I suggested below would be best, or simply showing
the output scrolling by would have the most impact. Perhaps both, as in
a message "Testing accuracy of linear regression..." in a message window
while the output scrolled by in the console.
would be to end the installation with a message pointing people to a
function like validate.R() and an equivalent menu selection as a
following step. That would ensure that everyone knows the option exists,
plus it enables any R user to run the tests for skeptics at any time.
The easier it is to run the test suite the better.
impractical for most people to run. In that case, perhaps just a subset
could be compiled, with an emphasis on testing the common statistical
functions that people are likely to focus their concern upon.
waste of time, and technically it is. But psychologically this testing
will have a important impact that will silence many critics. Thanks for
taking the time to consider it.

Now that I've asked you in, I probably should at least chip in with a 
couple of brief notes on the issue:

- not everything can be validated, and it's not like the commercial 
companies are validating everything. E.g. nonlinear regression code will 
give different results on different architectures, or even different 
compilers on the same architecture, and may converge on one and not on 
another.

- end-user validation is in principle a good thing, but please notice 
that what we currently do is part of a build from sources, and requires 
that build tools are installed. (E.g., we don't just run things, we also 
compare them to known outputs.) It's not entirely trivial to push these 
techniques to the end user.

- a good reason to want post-install validation is that validity can 
depend on other part of the system outside developer control (e.g. an 
overzealous BLAS optimization, sacrificing accuracy and/or standards 
compliance for speed, can cause trouble). This is also a reason for not 
making too far-reaching statements about validity.

- I'm not too happy about maintaining the same information in multiple 
places. One thing we learned from the FDA document is how easily factual 
errors creep in and how silly we'd look if, say, the location of a key 
server got stated incorrectly, or say that we release one patch version 
when in fact the most recent one had two. This kind of authoritative 
document itself needs a verification process to ensure that it is correct.

Best,

-pd