[Rd] requesting a mentor for R development

[Ben Bolker]

Paul Johnson <pauljohn32 <at> gmail.com> writes:

> 
> I'd like to learn the process of revising R functions & packages and
> then submitting proposed patches to the R Core team.  Would someone be
> willing to mentor me through one example?

  I don't know about mentoring, but I'll give my two cents (some
specific and some general thoughts, and some of my own questions).

> For starters, consider an example.  I'd like to revise the t.test
> function to return the stderr value to the user.  We only need to
> change the "rval" in the third-from-the end line of
> stats:::t.test.default.
> 
> Change this:
> 
>  rval <- list(statistic = tstat, parameter = df, p.value = pval,
>         conf.int = cint, estimate = estimate, null.value = mu,
>         alternative = alternative, method = method, data.name = dname)
>     class(rval) <- "htest"
>     return(rval)
> 
> To this:
> 
>  rval <- list(statistic = tstat, parameter = df, stderr=stderr, p.value = pval,
>         conf.int = cint, estimate = estimate, null.value = mu,
>         alternative = alternative, method = method, data.name = dname)
>     class(rval) <- "htest"
>     return(rval)
> 
> Here is where I need help.
> 
> 1. What other changes in the R code & documents would be required for
> consistency?

  You would certainly want to modify the corresponding manual page.
  
  There is an issue with fitting this specific change into the existing
R framework.  't.test' returns an object of class 'htest', which is
printed using 'stats:::print.htest'.  I haven't actually tried it,
but it looks to me as though print.htest (which is intended to
be a generic class for statistical test -- maybe h stands for
"hypothesis", I don't know) will simply ignore "stderr" or
any other non-default components of an 'htest' object.
There is a '...' argument to 'print.htest', but it functions
to pass options to print() for the estimate and the null values.

  I haven't been able to find any specific documentation about
htest.  print.htest() is used for a wide range of tests (in the
stats package and many contributed packages), so obviously it
would be bad to make non-backward-compatible changes.  I think
it might be best to modify print.htest() so it looked
for any additional/non-standard components of the object and
printed them after all the other output (they would need to
have reasonable labels incorporated somehow too).


> 
> 2. How does R Core Team expect/accept patches?
> I do understand a bit about SVN and CVS.  I think I could mark this up
> and make a diff, but I'm uncertain about the details.

  I think that patches via "svn diff" against the latest SVN are
preferred. The only routes I know for submission are (1) sending
patch files to R-devel or (2) submitting them to the R bugs system
as a "wishlist" item.  I don't know which is preferred.

> 3. How would I best  prepare a suggestion like this so as to get it
> accepted into R?

  I think the accepted method (although I don't know whether this
is documented anywhere) is to do what you have done, submitting a
"request for discussion" on r-devel, getting it discussed, posting
patches for comment, and hoping for the best.