[Rd] how to document stuff most users don't want to see

spencerg spencer.graves at prodsyse.com
Mon Oct 5 21:01:32 CEST 2009


There are many arguments in many functions that are rarely used.  I 
prefer to see it all documented in the help pages.  If they are not 
documented in the help pages (and sometimes even if they are), a user 
who wants them can invent other ways to get similar information with 
much greater effort, and do so for years only to eventually find a much 
easier way buried in the documentation.  Example:  I was frustrated for 
years that "nls" would refuse to produce output if it did not converge.  
I often used "optim" instead of "nls" for that reason.  However, the 
list returned by "optim" does not have the nice methods that one can use 
with an "nls" object.  Eventually, I found the "warnOnly" option 
documented under "nls.control", which has made "nls" easier for me to use. 

Spencer Graves


William Dunlap wrote:
> There are several help files in the R sources that
> describe concepts and not particular R objects.
> E.g., help(Methods), help(Syntax), and help(regex).
> They don't have a docType  entry and their alias
> entries do not refer to functions.  Perhaps your
> debugging documentation could go into a similar
> *.Rd file.
>
> Does check balk at such help files in a package? Should it?
> Should there be a special docType for such help files?
>
> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap tibco.com  
>
>   
>> -----Original Message-----
>> From: r-devel-bounces at r-project.org 
>> [mailto:r-devel-bounces at r-project.org] On Behalf Of Charles Geyer
>> Sent: Monday, October 05, 2009 10:51 AM
>> To: r-devel at r-project.org
>> Subject: [Rd] how to document stuff most users don't want to see
>>
>> The functions metrop and temper in the mcmc package have a 
>> debug = FALSE
>> argument that when TRUE adds a lot of debugging information 
>> to the returned
>> list.  This is absolutely necessary to test the functions, because one
>> generally knows nothing about the simulated distribution 
>> except what what
>> one learns from MCMC samples.  Hence you must expose all 
>> details of the
>> simulation to have any hope of checking that it is doing what 
>> it is supposed
>> to do.  However, this information is of interested mostly 
>> (perhaps solely)
>> to developers.  So I didn't document it in the Rd files for 
>> these functions.
>>
>> But it has ocurred to me that people might be interested in 
>> how these functions
>> are validated, and I would like to document the debug output 
>> somewhere, but I
>> don't want to clutter up the documentation that ordinary 
>> users see.  That
>> suggests a separate help page for debugging.  Looking at 
>> "Writing R Extensions"
>> it doesn't seem like there is a type of Rd file for this 
>> purpose.  I suppose
>> it could be added in (fairly long) sections titled "Debug 
>> Output" in metrop.Rd
>> and temper.Rd or it could be put in a package help page 
>> (although that's not
>> what that kind of page is really for).  Any other 
>> possibilities to consider?
>> -- 
>> Charles Geyer
>> Professor, School of Statistics
>> University of Minnesota
>> charlie at stat.umn.edu
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>     
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>   


-- 
Spencer Graves, PE, PhD
President and Chief Operating Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph:  408-655-4567



More information about the R-devel mailing list