R devel - Jun 2011 - requesting a mentor for R development

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?

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?

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.

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

If somebody will raise a hand, I'm willing to do the work to learn.

pj
-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas

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.