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 l
On 10/5/2009 1:50 PM, Charles Geyer wrote:
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
roject.org] On Behalf Of Charles Geyer
> Sent: Monday, October 05, 2009 10:51 AM
> To: r-devel@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
rg] On Behalf Of Charles Geyer
Sent: Monday, October 05, 2009 10:51 AM
To: r-devel@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 inform
---Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Charles Geyer
Sent: Monday, October 05, 2009 10:51 AM
To: r-devel@r-project.org
Subject: [Rd] how to document stuff most users don't want to see
The functions metrop and temper in
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 hel
Writing good documentation is hard. I can appreciate the desire to
find technological solutions that improve documentation. However, the
benefit of a help system that allows for varying degrees of verbosity
is very likely to be overshadowed by the additional complexity imposed
on the help system.
I write *.Rd files primarily because it helps me think through what I
want the software to do AND because the "\examples" provide any degree
of unit testing I feel I need to create "trustworth software" (to quote
Chambers). The fact that I can then share the resulting package with
others is a
Under the system of development we
now have, I agreee with Seth's
assertion. But if there were
people dedicated to documentation,
then I think something like what I
described could be workable.
Pat
Seth Falcon wrote:
Writing good documentation is hard. I can appreciate the desire to
find tec
Charles Geyer
Sent: Monday, October 05, 2009 10:51 AM
To: r-devel@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
> -Original Message-
> From: Patrick Burns [mailto:pbu...@pburns.seanet.com]
> Sent: Tuesday, October 06, 2009 12:53 AM
> To: spencerg
> Cc: William Dunlap; char...@stat.umn.edu; r-devel@r-project.org
> Subject: Re: [Rd] how to document stuff most users don't want
If help was only displayed in the form of html pages, one could
perhaps mimic the javascript trick sometimes found in wikipedia, e.g.
"http://en.wikipedia.org/wiki/Mathematical_induction#Example"; (see the
"show/hide" toggle at the bottom).
I don't see how this could work with plain text or pdf ou
On Mon, Oct 05, 2009 at 02:03:51PM -0400, Duncan Murdoch wrote:
> On 10/5/2009 1:50 PM, Charles Geyer wrote:
> >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 necess
13 matches
Mail list logo
