Re: [Rd] S4 methods for "+"
On 25 Aug 2006, at 12:56, Prof Brian Ripley wrote:
> Just like any other S4 method:
>
> setMethod("+", c("track", "track"),
> function(e1, e2) new("track", x=c([EMAIL PROTECTED], [EMAIL
> PROTECTED]), y=c
> ([EMAIL PROTECTED],[EMAIL PROTECTED])))
>
> If you want to write a group generic for the S4 Ops group, you do it
> very like S3. There are worked examples in 'S Programming' (that
> at least
> at one point worked in R).
>
I had a long train journey over the weekend and took S Programming
with me. Most of my questions about S4 methods can be answered
by reading chapters 4 and 5 over and over and over again, with
occasional
reference to the Green Book.
?SetMethod does not reference Venables & Ripley. Could this be added?
>
> On Fri, 25 Aug 2006, Robin Hankin wrote:
>
>> Hi
>>
>> I'm trying to implement S4 methods in a package, and I am having
>> difficulty defining "+" to do what I want.
>>
>> In the Green Book, there is a discussion of a "track" object,
>>
>> setClass("track", representation(x="numeric", y="numeric"))
>>
>> OK.
>>
>> track1 <- new("track",x=c(1,4,6),y=c(10,11,12))
>> track2 <- new("track",x=c(2,5),y=c(100,101))
>>
>>
>> What I want to do is to define "+" for track object so that if
>>
>> track3 <- track1 + track2
>>
>> has [EMAIL PROTECTED] == c(1,2,4,5,6)
>> and
>> [EMAIL PROTECTED] = c(10,100,11,101,12)
>>
>> maybe adding a track object to a scalar would shift the values of the
>> x slot.
>>
>> The algorithm itself is no problem...but what is the S4 equivalent to
>> the S3 technique of writing an Ops.track() function that tells
>> R what "+" means?
>>
>>
>>
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PATCH: Add fields argument to installed.packages and available.packages
> "Seth" == Seth Falcon <[EMAIL PROTECTED]> > on Mon, 28 Aug 2006 17:42:39 -0700 writes: Seth> Hi all, The write_PACKAGES function has a 'fields' Seth> argument that allows a user generating a PACKAGES file Seth> to specify additional fields to include. For Seth> symmetry, it would be nice for the available.packages Seth> function to be able to read those extra fields when Seth> specified. Seth> Similarly, it would be useful for installed.packages Seth> to have a 'fields' argument. This would allow a user Seth> to query the set of installed packages for other Seth> fields in the DESCRIPTION file. Seth> One use for this would be for repository hosters to Seth> include the License field in their PACKAGES file. In Seth> this way, end users could query a repository and only Seth> download packages that they have a license to use. Seth> Below is a patch against svn 38996 that attempts to Seth> implement this. I like the idea and will look into applying the patch (note there's at least one typo which makes "make check" fail: /priotiry/) A propos: A while back (in last summer?), we (some of R-core) have discussed about a new field to be added to DESCRIPTION, and AFAIR, the only problem we had, is to find a name we all liked. Or was there more then the name alone, and some where convinced that it is superfluous and hence too complicated. The idea was a field related to but weaker than 'Suggests' : Something like 'canMakeUseOf: [, , ... ] which is *not* used in any QA/QC checking, but is purely informative: If is require()able, then some examples may look nicer, a function may provide another feature, etc, etc. Alternatives to 'canMakeUseOf' would have been 'isHappilyCoworkingWith' What do you (R-devel listeners) think about the idea? Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] vector S4 classes
In the Green Book, section 7.5 discusses new vector classes and uses
quaternions
as an example of a vector class that needs more than one number per
element.
I would like to define a new class that has a numeric vector and a
logical
vector of the same length that specifies whether the measurement was
accurate.
The following code does not behave as desired:
> setClass("thing",representation("vector",accurate="logical"))
[1] "thing"
> dput(x <- new("thing",1:10,accurate=rep(T,10)))
structure(c(1, 2, 3, 4, 5, 6, 7, 8, 9, 10), accurate = c(TRUE,
TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE), class =
structure("thing", package = ".GlobalEnv"))
> x[1:3]
[1] 1 2 3
> dput(x[1:3])
c(1, 2, 3)
>
because, although the "accurate" slot is filled as desired in "x",
when extracting the first
three elements, it seems to be lost.
What is the appropriate setClass() call to do what I want? Or indeed
is making "thing"
a vector class as sensible idea here?
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vector S4 classes
> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
> on Tue, 29 Aug 2006 10:42:21 +0100 writes:
Robin> In the Green Book, section 7.5 discusses new vector classes and uses
Robin> quaternions
Robin> as an example of a vector class that needs more than one number per
Robin> element.
Robin> I would like to define a new class that has a numeric vector and a
Robin> logical
Robin> vector of the same length that specifies whether the measurement was
Robin> accurate.
Robin> The following code does not behave as desired:
>> setClass("thing",representation("vector",accurate="logical"))
Robin> [1] "thing"
>> dput(x <- new("thing",1:10,accurate=rep(T,10)))
Robin> structure(c(1, 2, 3, 4, 5, 6, 7, 8, 9, 10), accurate = c(TRUE,
Robin> TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE), class =
Robin> structure("thing", package = ".GlobalEnv"))
>> x[1:3]
Robin> [1] 1 2 3
>> dput(x[1:3])
Robin> c(1, 2, 3)
>>
Robin> because, although the "accurate" slot is filled as desired in "x",
Robin> when extracting the first
Robin> three elements, it seems to be lost.
and you would really expect that ``R'' magically knows to it
also must subset the accurate slote ?
Robin> What is the appropriate setClass() call to do what I want? Or
indeed
Robin> is making "thing"
Robin> a vector class as sensible idea here?
I think you need to define at least a subset and subassign
method for your class as well.
Defining it as "vector" will automatically inherit all the
method definitions for "vector" --- none of which will ``know anything''
about the accuracy slot.
Therefore, I tend to think you rather define a class with "all slots"
setClass("Thing", representation(x = "numeric", accurate = "logical"))
and then you probably have to define many methods for that
class, notably for "[" and also "[<-" where the latter should
happen via setReplaceMethod("Thing",
Also, I'd define a validity method, where you have to decide if
'accurate' must have the same length as 'x' -- or what it should
mean if not.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vector S4 classes
Hi Martin
thanks for this. I see what you say about R not being able to
magically subset the
"accuracy" slot. Which leaves me puzzled as to why anyone would define
a vector class such as "string" (p315). I can't see why "string" is
defined as
it is, rather than use something like "fungi" from V&R chapter 5.
So, my next question is, why does the Green Book recommend
setClass("quaternion", "vector", prototype=numeric())
?
Why not do what the "onion" package does and make a quaternion
a single column of a four-row matrix? What advantage does the
setClass() method above have over the single-column-of-a-four-row-matrix
method?
best wishes
Robin
On 29 Aug 2006, at 11:11, Martin Maechler wrote:
>> "Robin" == Robin Hankin <[EMAIL PROTECTED]>
>> on Tue, 29 Aug 2006 10:42:21 +0100 writes:
>
> Robin> In the Green Book, section 7.5 discusses new vector
> classes and uses
> Robin> quaternions
> Robin> as an example of a vector class that needs more than one
> number per
> Robin> element.
>
> Robin> I would like to define a new class that has a numeric
> vector and a
> Robin> logical
> Robin> vector of the same length that specifies whether the
> measurement was
> Robin> accurate.
>
> Robin> The following code does not behave as desired:
>
>>> setClass("thing",representation("vector",accurate="logical"))
> Robin> [1] "thing"
>>> dput(x <- new("thing",1:10,accurate=rep(T,10)))
> Robin> structure(c(1, 2, 3, 4, 5, 6, 7, 8, 9, 10), accurate = c
> (TRUE,
> Robin> TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE),
> class =
> Robin> structure("thing", package = ".GlobalEnv"))
>>> x[1:3]
> Robin> [1] 1 2 3
>>> dput(x[1:3])
> Robin> c(1, 2, 3)
>>>
>
> Robin> because, although the "accurate" slot is filled as
> desired in "x",
> Robin> when extracting the first
> Robin> three elements, it seems to be lost.
>
> and you would really expect that ``R'' magically knows to it
> also must subset the accurate slote ?
>
> Robin> What is the appropriate setClass() call to do what I
> want? Or indeed
> Robin> is making "thing"
> Robin> a vector class as sensible idea here?
>
> I think you need to define at least a subset and subassign
> method for your class as well.
>
> Defining it as "vector" will automatically inherit all the
> method definitions for "vector" --- none of which will ``know
> anything''
> about the accuracy slot.
> Therefore, I tend to think you rather define a class with "all slots"
>
> setClass("Thing", representation(x = "numeric", accurate =
> "logical"))
>
> and then you probably have to define many methods for that
> class, notably for "[" and also "[<-" where the latter should
> happen via setReplaceMethod("Thing",
>
> Also, I'd define a validity method, where you have to decide if
> 'accurate' must have the same length as 'x' -- or what it should
> mean if not.
>
> Martin
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vector S4 classes
You might want to look at the source for the R 'its' package. It defines
an S4 class for an irregular time series whose representation
consists of
1. a matrix portion analogous to your vector portion to hold the series
of multivariate series, and
2. a "dates" slot analogous to your accurate slot
and defines numerous methods for this class.
On 8/29/06, Robin Hankin <[EMAIL PROTECTED]> wrote:
> In the Green Book, section 7.5 discusses new vector classes and uses
> quaternions
> as an example of a vector class that needs more than one number per
> element.
>
> I would like to define a new class that has a numeric vector and a
> logical
> vector of the same length that specifies whether the measurement was
> accurate.
>
> The following code does not behave as desired:
>
> > setClass("thing",representation("vector",accurate="logical"))
> [1] "thing"
> > dput(x <- new("thing",1:10,accurate=rep(T,10)))
> structure(c(1, 2, 3, 4, 5, 6, 7, 8, 9, 10), accurate = c(TRUE,
> TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE, TRUE), class =
> structure("thing", package = ".GlobalEnv"))
> > x[1:3]
> [1] 1 2 3
> > dput(x[1:3])
> c(1, 2, 3)
> >
>
> because, although the "accurate" slot is filled as desired in "x",
> when extracting the first
> three elements, it seems to be lost.
>
> What is the appropriate setClass() call to do what I want? Or indeed
> is making "thing"
> a vector class as sensible idea here?
>
>
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PATCH: Add fields argument to installed.packages and available.packages
Martin Maechler wrote:
> ...
>
>The idea was a field related to but weaker than 'Suggests' :
>Something like
> 'canMakeUseOf: [, , ... ]
>which is *not* used in any QA/QC checking, but is purely
>informative: If is require()able, then some examples may
>look nicer, a function may provide another feature, etc, etc.
>Alternatives to 'canMakeUseOf' would have been
>'isHappilyCoworkingWith'
>
>What do you (R-devel listeners) think about the idea?
>
>
I still like this idea. I prefer 'canMakeUseOf' to
'isHappilyCoworkingWith' mainly because it seems less ambiguous.
Paul Gilbert
>Martin
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field [was ".. Add 'fields' argument ..]
> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
> on Tue, 29 Aug 2006 09:55:09 -0400 writes:
PaulG> Martin Maechler wrote:
>> ...
>>
>> The idea was a field related to but weaker than 'Suggests' :
>> Something like
>> 'canMakeUseOf: [, , ... ]
>> which is *not* used in any QA/QC checking, but is purely
>> informative: If is require()able, then some examples may
>> look nicer, a function may provide another feature, etc, etc.
>> Alternatives to 'canMakeUseOf' would have been
>> 'isHappilyCoworkingWith'
>>
>> What do you (R-devel listeners) think about the idea?
PaulG> I still like this idea. I prefer 'canMakeUseOf' to
PaulG> 'isHappilyCoworkingWith' mainly because it seems less ambiguous.
Thanks, Paul.
As you may have guessed I should have put a " :-) " beside the
'isHappily...' .
Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
is rather too long, but before finding the proper term, we should
agree on usefulness of such a new field.
Apart from the use of package authors {some could note that
other packages make use of theirs, without already depending on
or suggesting them}, it's one of those fields that should help
in the future to explore (e.g. cluster or neighborhood-graph)
the growing high-dimensional space of R packages.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field [was ".. Add 'fields' argument ..]
>> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
>> on Tue, 29 Aug 2006 09:55:09 -0400 writes:
>
>PaulG> Martin Maechler wrote:
>>> ...
>>>
>>> The idea was a field related to but weaker than 'Suggests' :
>>> Something like
>>> 'canMakeUseOf: [, , ... ]
>>> which is *not* used in any QA/QC checking, but is purely
>>> informative: If is require()able, then some examples may
>>> look nicer, a function may provide another feature, etc, etc.
>>> Alternatives to 'canMakeUseOf' would have been
>>> 'isHappilyCoworkingWith'
>>>
>>> What do you (R-devel listeners) think about the idea?
>
>PaulG> I still like this idea. I prefer 'canMakeUseOf' to
>PaulG> 'isHappilyCoworkingWith' mainly because it seems
>less ambiguous.
>
>Thanks, Paul.
>As you may have guessed I should have put a " :-) " beside the
>'isHappily...' .
>
>Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
>is rather too long, but before finding the proper term, we should
>agree on usefulness of such a new field.
>Apart from the use of package authors {some could note that
>other packages make use of theirs, without already depending on
>or suggesting them}, it's one of those fields that should help
>in the future to explore (e.g. cluster or neighborhood-graph)
>the growing high-dimensional space of R packages.
>
Hello Martin, hello Paul,
this is an interesting iniative! There are already 'task views' (I do
not have to tell you :-); with a growing number of packages contained in
each) and hence, the 'value added', IMHO, of such a field in the
DESCRIPTION file would be to narrow down the search to affiliated
packages. Incidentally, these packages might not be contained in a
certain task view and the advantage is threefold: first this give
package authors the leeway to decide which packages should go 'hand in
hand' with their one(s); secondly, users might be pointed to packages,
that would have slipped their attention by only spotting at a certain
task view and last but not least, not all packages do appear in a task
view.
Just my 2c.
Best,
Bernhard
>Martin
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
*
Confidentiality Note: The information contained in this mess...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PATCH: Add fields argument to installed.packages and available.packages
Martin Maechler <[EMAIL PROTECTED]> writes: > I like the idea and will look into applying the patch > (note there's at least one typo which makes "make check" fail: > /priotiry/) Great. Sorry for the typo, I've sent an update privately. > A propos: > > A while back (in last summer?), we (some of R-core) have > discussed about a new field to be added to DESCRIPTION, > and AFAIR, the only problem we had, is to find a name we > all liked. > Or was there more then the name alone, and some where convinced > that it is superfluous and hence too complicated. > > The idea was a field related to but weaker than 'Suggests' : > Something like > 'canMakeUseOf: [, , ... ] > which is *not* used in any QA/QC checking, but is purely > informative: If is require()able, then some examples may > look nicer, a function may provide another feature, etc, etc. > Alternatives to 'canMakeUseOf' would have been > 'isHappilyCoworkingWith' > > What do you (R-devel listeners) think about the idea? Some thoughts: * Beyond strict dependencies, it is useful for a package to be able to declare that it "can use" other packages to provide additional features _which may be platform specific_. * It is useful to be able to check the non-optional parts when non-essential packages are not available. In the case of platform specific optional features, this is essential. Otherwise it would be impossible to ever run check. * Package vignettes, used heavily in Bioconductor, often require a set of packages to be available to provide data and functions for a coherent example analysis. These extra packages are often not used directly by the package itself (neither dependency nor "can use"). A similar issue arises for examples included in package documentation. * It is useful to be able to check only those vignettes and examples where the required packages available. * If I were a new user/developer coming to R and read about Depends, Suggests, and CanMakeUseOf, I would likely be confused. With that in mind, I wonder if: Suggests could mean "can use" and a compromise of some sort be established w.r.t. to R CMD check (similar to --no-vignettes). Depends.examples (or similar) be added which lists dependencies for documentation examples and vignettes. Best Wishes, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Capturing warnings with capture.output
Is there any way to include warnings in the output from capture.output? eg:
a <- capture.output(warning("test"))
all.equal(a, "Warning message: \n test ")
Conceptually, this seems like redirecting stderr to stdout, or somehow
changing warning to simple print it's output. I've had a look at
tryCatch and using a warning handler, but this terminates execution at
the warning.
Thanks,
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field [was ".. Add 'fields' argument ..]
CanUse?
If the 'Suggests' field "lists packages that are not necessarily needed"
(Writing R Extensions), then why is the user required to have the
package installed to pass R CMD check? Likewise, if a CanMakeUseOf field
is added, then why would one choose to use Suggests at all? That is, is
there an advantage to requiring that the user have a package available
(to pass R CMD check) even if they do not need to load it to get
functionality?
I occasionally write functions of the form:
if (require(pkg)) optimizedCode() else regularCode()
which works better for users who have installed additional packages, but
does not fail if the user has not. Such a field would be a nice addition
to inform users that getting an additional package might be
advantageous.
Cheers,
Robert
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Maechler
Sent: Tuesday, August 29, 2006 10:13 AM
To: Paul Gilbert
Cc: r-devel@stat.math.ethz.ch
Subject: Re: [Rd] 'CanMakeUseOf' field [was ".. Add 'fields' argument
..]
> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
> on Tue, 29 Aug 2006 09:55:09 -0400 writes:
PaulG> Martin Maechler wrote:
>> ...
>>
>> The idea was a field related to but weaker than 'Suggests' :
>> Something like
>> 'canMakeUseOf: [, , ... ]
>> which is *not* used in any QA/QC checking, but is purely
>> informative: If is require()able, then some examples may
>> look nicer, a function may provide another feature, etc, etc.
>> Alternatives to 'canMakeUseOf' would have been
>> 'isHappilyCoworkingWith'
>>
>> What do you (R-devel listeners) think about the idea?
PaulG> I still like this idea. I prefer 'canMakeUseOf' to
PaulG> 'isHappilyCoworkingWith' mainly because it seems less
ambiguous.
Thanks, Paul.
As you may have guessed I should have put a " :-) " beside the
'isHappily...' .
Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
is rather too long, but before finding the proper term, we should
agree on usefulness of such a new field.
Apart from the use of package authors {some could note that
other packages make use of theirs, without already depending on
or suggesting them}, it's one of those fields that should help
in the future to explore (e.g. cluster or neighborhood-graph)
the growing high-dimensional space of R packages.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PATCH: Add fields argument to installed.packages and available.packages
Rather than a plethora of fields, perhaps the Depends field could indicate what depends on the object: For example, if we use file extensions to indicate what is dependent then one might write this to indicate that some .Rd (i.e. examples) and .Rnw (i.e. vignette) files depend on lattice and the entire package depends on zoo and the package is related to but not dependent on tseries: Depends: lattice (.Rd, .Rnw), grid (.Rnw), zoo, tseries (0) Then there could be rules for each such suffix when processing the package. This has the advantage that its meaning is more obvious than a bunch of keywords (Depends, Suggests, CanUse, Related). On 8/29/06, Martin Maechler <[EMAIL PROTECTED]> wrote: > > "Seth" == Seth Falcon <[EMAIL PROTECTED]> > > on Mon, 28 Aug 2006 17:42:39 -0700 writes: > >Seth> Hi all, The write_PACKAGES function has a 'fields' >Seth> argument that allows a user generating a PACKAGES file >Seth> to specify additional fields to include. For >Seth> symmetry, it would be nice for the available.packages >Seth> function to be able to read those extra fields when >Seth> specified. > >Seth> Similarly, it would be useful for installed.packages >Seth> to have a 'fields' argument. This would allow a user >Seth> to query the set of installed packages for other >Seth> fields in the DESCRIPTION file. > >Seth> One use for this would be for repository hosters to >Seth> include the License field in their PACKAGES file. In >Seth> this way, end users could query a repository and only >Seth> download packages that they have a license to use. > >Seth> Below is a patch against svn 38996 that attempts to >Seth> implement this. > > I like the idea and will look into applying the patch > (note there's at least one typo which makes "make check" fail: > /priotiry/) > > A propos: > > A while back (in last summer?), we (some of R-core) have > discussed about a new field to be added to DESCRIPTION, > and AFAIR, the only problem we had, is to find a name we > all liked. > Or was there more then the name alone, and some where convinced > that it is superfluous and hence too complicated. > > The idea was a field related to but weaker than 'Suggests' : > Something like > 'canMakeUseOf: [, , ... ] > which is *not* used in any QA/QC checking, but is purely > informative: If is require()able, then some examples may > look nicer, a function may provide another feature, etc, etc. > Alternatives to 'canMakeUseOf' would have been > 'isHappilyCoworkingWith' > > What do you (R-devel listeners) think about the idea? > > Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capturing warnings with capture.output
Something like this which displays the warnings and also writes
them to out so that they are captured:
out <- capture.output(
withCallingHandlers({
print(1)
warning("A warning.")
print(2)
warning("Another warning.")
print(3)
}, warning = function(x) cat(x$message, "\n"))
)
print(out)
On 8/29/06, hadley wickham <[EMAIL PROTECTED]> wrote:
> Is there any way to include warnings in the output from capture.output? eg:
>
> a <- capture.output(warning("test"))
> all.equal(a, "Warning message: \n test ")
>
> Conceptually, this seems like redirecting stderr to stdout, or somehow
> changing warning to simple print it's output. I've had a look at
> tryCatch and using a warning handler, but this terminates execution at
> the warning.
>
> Thanks,
>
> Hadley
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] arguments to boxplot( ) not passed to bxp() (PR#9183)
Full_Name: Landon Sego Version: 2.3.1 OS: Windows Submission from: (NULL) (130.20.54.241) # When calling boxplot(), shouldn't the "axes" and "frame.plot" # arguments get passed down to bxp()? # Two examples where the "frame.plot" and "axes" arguments # don't seem to work the way one would anticipate: X <- data.frame(x=as.factor(rep(c(1,2,3), 10)), y=rnorm(30)) # Removes the axes, but doesn't frame the plot boxplot(y~x, data=X, axes=FALSE, frame.plot=TRUE) # Both axes and frame are present boxplot(y~x, data=X, axes=TRUE, frame.plot=FALSE) # However, if we explictly use bxp(), the arguments work as # we would expect: Y <- boxplot(y~x, data=X, plot=FALSE) # Frames plot and no axes bxp(Y, frame.plot=TRUE, axes=FALSE) # Produces axes with no frame bxp(Y, frame.plot=FALSE) # If I'm mistaken (or misinformed) and this isn't a bug, # please accept my apologies in advance. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field [was ".. Add 'fields' argument ..]
On 8/29/2006 10:12 AM, Martin Maechler wrote:
>> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
>> on Tue, 29 Aug 2006 09:55:09 -0400 writes:
>
> PaulG> Martin Maechler wrote:
> >> ...
> >>
> >> The idea was a field related to but weaker than 'Suggests' :
> >> Something like
> >> 'canMakeUseOf: [, , ... ]
> >> which is *not* used in any QA/QC checking, but is purely
> >> informative: If is require()able, then some examples may
> >> look nicer, a function may provide another feature, etc, etc.
> >> Alternatives to 'canMakeUseOf' would have been
> >> 'isHappilyCoworkingWith'
> >>
> >> What do you (R-devel listeners) think about the idea?
>
> PaulG> I still like this idea. I prefer 'canMakeUseOf' to
> PaulG> 'isHappilyCoworkingWith' mainly because it seems less ambiguous.
>
> Thanks, Paul.
> As you may have guessed I should have put a " :-) " beside the
> 'isHappily...' .
>
> Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
> is rather too long, but before finding the proper term, we should
> agree on usefulness of such a new field.
> Apart from the use of package authors {some could note that
> other packages make use of theirs, without already depending on
> or suggesting them}, it's one of those fields that should help
> in the future to explore (e.g. cluster or neighborhood-graph)
> the growing high-dimensional space of R packages.
I think we need an option to R CMD check rather than a new field in the
DESCRIPTION. Currently a package could be mentioned for any of these
reasons:
1. To make functions, examples or vignettes work
2. To allow optional functionality in functions, examples or vignettes.
3. Because it contains complementary functions.
I don't think we really need to worry about 3: it should be contained
in 1 or 2, if reasonably complete examples are given.
Case 1 is handled by Depends.
An author should check case 2 both with and without the suggested
package. A user might be satisfied with a simple check "as things
currently stand", or might want a stringent check like the author wants.
The author can't know that, because it will depend on the user.
So I don't think this is something that should be changed in
DESCRIPTION. There should be an option to R CMD check to include or
exclude packages mentioned in the Suggests entry. (I'd suggest a 3
level option: check as though they are not available, check as
currently installed, require that they be available.)
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
Duncan Murdoch <[EMAIL PROTECTED]> writes: > I think we need an option to R CMD check rather than a new field in the > DESCRIPTION. Currently a package could be mentioned for any of these > reasons: > > 1. To make functions, examples or vignettes work > 2. To allow optional functionality in functions, examples or vignettes. > 3. Because it contains complementary functions. > > I don't think we really need to worry about 3: it should be contained > in 1 or 2, if reasonably complete examples are given. > > Case 1 is handled by Depends. I think there is an important distinction between a dependency needed for the package to function and a dependency needed to demonstrate said functionality via an example or vignette. The former is what Depends is about, the latter is something else (Suggests). > An author should check case 2 both with and without the suggested > package. A user might be satisfied with a simple check "as things > currently stand", or might want a stringent check like the author wants. > The author can't know that, because it will depend on the user. > > So I don't think this is something that should be changed in > DESCRIPTION. There should be an option to R CMD check to include or > exclude packages mentioned in the Suggests entry. (I'd suggest a 3 > level option: check as though they are not available, check as > currently installed, require that they be available.) I like this approach and agree in general that a solution involving changes to R CMD check might be the best as opposed to adding fields. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
On 8/29/2006 11:58 AM, Seth Falcon wrote: > Duncan Murdoch <[EMAIL PROTECTED]> writes: >> I think we need an option to R CMD check rather than a new field in the >> DESCRIPTION. Currently a package could be mentioned for any of these >> reasons: >> >> 1. To make functions, examples or vignettes work >> 2. To allow optional functionality in functions, examples or vignettes. >> 3. Because it contains complementary functions. >> >> I don't think we really need to worry about 3: it should be contained >> in 1 or 2, if reasonably complete examples are given. >> >> Case 1 is handled by Depends. > > I think there is an important distinction between a dependency needed > for the package to function and a dependency needed to demonstrate > said functionality via an example or vignette. The former is what > Depends is about, the latter is something else (Suggests). Yes, that's a good point, especially with vignettes. Only the package author needs to be able to run them. But maybe examples should be considered broken if they don't work. Users should be able to expect example(foo) not to generate an error. Package authors should wrap optional examples in code like if (require(...)). Duncan Murdoch > >> An author should check case 2 both with and without the suggested >> package. A user might be satisfied with a simple check "as things >> currently stand", or might want a stringent check like the author wants. >> The author can't know that, because it will depend on the user. >> >> So I don't think this is something that should be changed in >> DESCRIPTION. There should be an option to R CMD check to include or >> exclude packages mentioned in the Suggests entry. (I'd suggest a 3 >> level option: check as though they are not available, check as >> currently installed, require that they be available.) > > I like this approach and agree in general that a solution involving > changes to R CMD check might be the best as opposed to adding fields. > > + seth > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field [was ".. Add 'fields' argument ..]
Duncan Murdoch wrote:
> On 8/29/2006 10:12 AM, Martin Maechler wrote:
>
>>> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
>>> on Tue, 29 Aug 2006 09:55:09 -0400 writes:
>>
>>
>> PaulG> Martin Maechler wrote:
>> >> ...
>> >> >> The idea was a field related to but weaker than
>> 'Suggests' :
>> >> Something like
>> >> 'canMakeUseOf: [, , ... ]
>> >> which is *not* used in any QA/QC checking, but is purely
>> >> informative: If is require()able, then some examples may
>> >> look nicer, a function may provide another feature, etc, etc.
>> >> Alternatives to 'canMakeUseOf' would have been
>> >> 'isHappilyCoworkingWith'
>> >> >> What do you (R-devel listeners) think about the idea?
>>
>> PaulG> I still like this idea. I prefer 'canMakeUseOf' to
>> PaulG> 'isHappilyCoworkingWith' mainly because it seems less ambiguous.
>>
>> Thanks, Paul.
>> As you may have guessed I should have put a " :-) " beside the
>> 'isHappily...' .
>>
>> Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
>> is rather too long, but before finding the proper term, we should
>> agree on usefulness of such a new field.
>> Apart from the use of package authors {some could note that
>> other packages make use of theirs, without already depending on
>> or suggesting them}, it's one of those fields that should help
>> in the future to explore (e.g. cluster or neighborhood-graph)
>> the growing high-dimensional space of R packages.
>
>
> I think we need an option to R CMD check rather than a new field in
> the DESCRIPTION. Currently a package could be mentioned for any of
> these reasons:
>
> 1. To make functions, examples or vignettes work
> 2. To allow optional functionality in functions, examples or vignettes.
> 3. Because it contains complementary functions.
>
> I don't think we really need to worry about 3: it should be contained
> in 1 or 2, if reasonably complete examples are given.
>
> Case 1 is handled by Depends.
Well, from "Writing R Extensions"
The optional Suggests field uses the same syntax as Depends and
lists packages that are not
necessarily needed. This includes packages used only in examples or
vignettes
So case 1 is handled by the combination of Depends and Suggests, and we
need something to handle case 2.
The related question is whether the CRAN checks should try to check 2,
or perhaps there needs to be 2a and 2b. There are cababilities (and
data) that CRAN may not have, so it would be nice distinguish things
that should be checked on CRAN from things that should not be.
Paul
>
> An author should check case 2 both with and without the suggested
> package. A user might be satisfied with a simple check "as things
> currently stand", or might want a stringent check like the author
> wants. The author can't know that, because it will depend on the user.
>
> So I don't think this is something that should be changed in
> DESCRIPTION. There should be an option to R CMD check to include or
> exclude packages mentioned in the Suggests entry. (I'd suggest a 3
> level option: check as though they are not available, check as
> currently installed, require that they be available.)
>
> Duncan Murdoch
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field [was ".. Add 'fields' argument ..]
On 8/29/2006 1:05 PM, Paul Gilbert wrote:
>
> Duncan Murdoch wrote:
>
>> On 8/29/2006 10:12 AM, Martin Maechler wrote:
>>
"PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
on Tue, 29 Aug 2006 09:55:09 -0400 writes:
>>>
>>>
>>> PaulG> Martin Maechler wrote:
>>> >> ...
>>> >> >> The idea was a field related to but weaker than
>>> 'Suggests' :
>>> >> Something like
>>> >> 'canMakeUseOf: [, , ... ]
>>> >> which is *not* used in any QA/QC checking, but is purely
>>> >> informative: If is require()able, then some examples may
>>> >> look nicer, a function may provide another feature, etc, etc.
>>> >> Alternatives to 'canMakeUseOf' would have been
>>> >> 'isHappilyCoworkingWith'
>>> >> >> What do you (R-devel listeners) think about the idea?
>>>
>>> PaulG> I still like this idea. I prefer 'canMakeUseOf' to
>>> PaulG> 'isHappilyCoworkingWith' mainly because it seems less ambiguous.
>>>
>>> Thanks, Paul.
>>> As you may have guessed I should have put a " :-) " beside the
>>> 'isHappily...' .
>>>
>>> Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
>>> is rather too long, but before finding the proper term, we should
>>> agree on usefulness of such a new field.
>>> Apart from the use of package authors {some could note that
>>> other packages make use of theirs, without already depending on
>>> or suggesting them}, it's one of those fields that should help
>>> in the future to explore (e.g. cluster or neighborhood-graph)
>>> the growing high-dimensional space of R packages.
>>
>>
>> I think we need an option to R CMD check rather than a new field in
>> the DESCRIPTION. Currently a package could be mentioned for any of
>> these reasons:
>>
>> 1. To make functions, examples or vignettes work
>> 2. To allow optional functionality in functions, examples or vignettes.
>> 3. Because it contains complementary functions.
>>
>> I don't think we really need to worry about 3: it should be contained
>> in 1 or 2, if reasonably complete examples are given.
>>
>> Case 1 is handled by Depends.
>
> Well, from "Writing R Extensions"
>The optional Suggests field uses the same syntax as Depends and
> lists packages that are not
>necessarily needed. This includes packages used only in examples or
> vignettes
Yes, Seth pointed that out too. Rather than adding additional levels,
I'd fix it by changing the wording:
1. To make functions work.
2. To make examples and vignettes work, or optional functionality in
functions.
The point is that there are some packages that are absolutely required
(listed in Depends), and some that are only sometimes required (listed
in Suggests). Gabor's suggestion of labelling how things are used could
be helpful too, but really even there, there are multiple levels of how
something is used.
> So case 1 is handled by the combination of Depends and Suggests, and we
> need something to handle case 2.
>
> The related question is whether the CRAN checks should try to check 2,
> or perhaps there needs to be 2a and 2b. There are cababilities (and
> data) that CRAN may not have, so it would be nice distinguish things
> that should be checked on CRAN from things that should not be.
I'd suggest that CRAN do its checks using the "as currently installed"
option proposed below. If a package can't pass tests using what's on
CRAN, then it should be marked as needing work.
Duncan Murdoch
>
> Paul
>
>>
>> An author should check case 2 both with and without the suggested
>> package. A user might be satisfied with a simple check "as things
>> currently stand", or might want a stringent check like the author
>> wants. The author can't know that, because it will depend on the user.
>>
>> So I don't think this is something that should be changed in
>> DESCRIPTION. There should be an option to R CMD check to include or
>> exclude packages mentioned in the Suggests entry. (I'd suggest a 3
>> level option: check as though they are not available, check as
>> currently installed, require that they be available.)
>>
>> Duncan Murdoch
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential info...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
Duncan Murdoch <[EMAIL PROTECTED]> writes: > On 8/29/2006 11:58 AM, Seth Falcon wrote: >> I think there is an important distinction between a dependency needed >> for the package to function and a dependency needed to demonstrate >> said functionality via an example or vignette. The former is what >> Depends is about, the latter is something else (Suggests). > > Yes, that's a good point, especially with vignettes. Only the package > author needs to be able to run them. Yes, but just to keep things clear: the value of vignettes is that users can follow along. So the ability to programatically identify the extra required packages is valuable. > But maybe examples should be considered broken if they don't > work. Users should be able to expect example(foo) not to generate an > error. Package authors should wrap optional examples in code like if > (require(...)). I agree. As with vignettes, there is value in users being able to follow along and it would be nice to have a programatic way to identify extra package needed for fancy/involved/optional examples. Best, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
Seth Falcon wrote:
>Duncan Murdoch <[EMAIL PROTECTED]> writes:
>
>
>>On 8/29/2006 11:58 AM, Seth Falcon wrote:
>>
>>
>>>I think there is an important distinction between a dependency needed
>>>for the package to function and a dependency needed to demonstrate
>>>said functionality via an example or vignette. The former is what
>>>Depends is about, the latter is something else (Suggests).
>>>
>>>
>>Yes, that's a good point, especially with vignettes. Only the package
>>author needs to be able to run them.
>>
>>
>
>Yes, but just to keep things clear: the value of vignettes is that
>users can follow along. So the ability to programatically identify
>the extra required packages is valuable.
>
>
>
>>But maybe examples should be considered broken if they don't
>>work. Users should be able to expect example(foo) not to generate an
>>error. Package authors should wrap optional examples in code like if
>>(require(...)).
>>
>>
This is a work around that is ok for the developer's testing and to
prevent failure on CRAN, and I use it. But, other than actually reading
the examples, it provides no hints to other testers or users about
things that might be installed, or installed first, to give more
complete testing and more functionality.
Looking toward the future, I think it would be useful to have a standard
mechanism to indicate extensions that are available in a package, and
might be tested and used, but are not necessarily available on CRAN. For
instance, an example might access to a purchased database or take
advantage of a computer cluster. It seems limiting to think that all
testing that cannot be done on CRAN must be done almost exclusively by
the developer.
Paul
>
>I agree. As with vignettes, there is value in users being able to
>follow along and it would be nice to have a programatic way to
>identify extra package needed for fancy/involved/optional examples.
>
>Best,
>
>+ seth
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
On 8/29/2006 2:24 PM, Paul Gilbert wrote:
> Seth Falcon wrote:
>
>>Duncan Murdoch <[EMAIL PROTECTED]> writes:
>>
>>
>>>On 8/29/2006 11:58 AM, Seth Falcon wrote:
>>>
>>>
I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette. The former is what
Depends is about, the latter is something else (Suggests).
>>>Yes, that's a good point, especially with vignettes. Only the package
>>>author needs to be able to run them.
>>>
>>>
>>
>>Yes, but just to keep things clear: the value of vignettes is that
>>users can follow along. So the ability to programatically identify
>>the extra required packages is valuable.
>>
>>
>>
>>>But maybe examples should be considered broken if they don't
>>>work. Users should be able to expect example(foo) not to generate an
>>>error. Package authors should wrap optional examples in code like if
>>>(require(...)).
>>>
>>>
> This is a work around that is ok for the developer's testing and to
> prevent failure on CRAN, and I use it. But, other than actually reading
> the examples, it provides no hints to other testers or users about
> things that might be installed, or installed first, to give more
> complete testing and more functionality.
I'm not saying to use this instead of Suggests, I'm saying to do both.
This way the Suggests entries really are suggestions: the examples will
run with or without the presence of the suggested packages.
I think there are so many variations on when a Suggested package should
be installed, that it's not reasonable to expect to be able to encode
them all in a machine readable way. They should be documented in human
readable format.
> Looking toward the future, I think it would be useful to have a standard
> mechanism to indicate extensions that are available in a package, and
> might be tested and used, but are not necessarily available on CRAN. For
> instance, an example might access to a purchased database or take
> advantage of a computer cluster. It seems limiting to think that all
> testing that cannot be done on CRAN must be done almost exclusively by
> the developer.
If by "mechanism" you mean human-readable documentation, I agree with
this.
Duncan Murdoch
>
> Paul
>
>>
>>I agree. As with vignettes, there is value in users being able to
>>follow along and it would be nice to have a programatic way to
>>identify extra package needed for fancy/involved/optional examples.
>>
>>Best,
>>
>>+ seth
>>
>>__
>>R-devel@r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential inform...{{dropped}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of runif() on different Operating Systems
No one else seems to have responded to this. Please see `Writing R Extensions' for how to time things in R. For things like this, the fine details of how well the compiler keeps the pipelines and cache filled are important, as is the cache size and memory speed. Using system.time(for (i in 1:500) ttt <- runif(100)) your Linux time looks slow, indeed slower than the only 32-bit Linux box I have left (a 2GHz 512Kb cache Xeon) and 2.5x slower than a 64-bit R on an 2.2GHz Opteron (which is doing a lot of other work and so only giving about 30% of one of its processors to R: the elapsed time was much longer). The binary distribution of R for Windows is compiled with -O3: for some tasks it makes a lot of difference and this might just be one. However, what can you usefully do in R with 5e8 random uniforms in anything like a minute, let alone the aggregate time this list will spend reading your question? If it matters to you, investigate the code your compiler creates. (The ATLAS developers report very poor performance on certain Pentiums for certain versions of gcc4.) On Mon, 28 Aug 2006, Martin Becker wrote: > Dear list, > > I have noticed surprisingly big performance differences of runif() > between Windows XP and (Debian) linux on similar CPUs (Pentium D 3.0GHz > (WinXP)/3.2GHz (Linux)) and I wonder if there is a simple explanation > for the difference. > On a linux system (with a slightly better CPU and 1GB more RAM), > execution of runif() seems to consume about 80% more CPU time than on a > Windows XP system. > On a Xeon 2.7GHz (Debian) linux I have checked, that using the .deb - > i386 - Version of R instead of a self-build i686 - version has no > noticeable effect on speed. > Measuring CPU time with Rprof() instead of Sys.time()-differences yields > similar results. You are not measuring CPU time at all with Sys.time. > Any hint is appreciated, please let me know, if the given information on > system/OS or the R output below is not sufficient. > > Regards, > > Martin Becker > > R - Output below > > Windows XP: (Pentium D, 3.0 GHz) > > > version >_ > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major 2 > minor 3.1 > year 2006 > month 06 > day01 > svn rev38247 > language R > version.string Version 2.3.1 (2006-06-01) > > RNGkind() > [1] "Mersenne-Twister" "Inversion" > > t1<-Sys.time();for (i in 1:500) ttt<-runif(100);print(Sys.time()-t1); > Time difference of 57.969 secs > > > > Debian Linux: (Pentium D, 3.2GHz) > > > version >_ > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major 2 > minor 3.1 > year 2006 > month 06 > day01 > svn rev38247 > language R > version.string Version 2.3.1 (2006-06-01) > > RNGkind() > [1] "Mersenne-Twister" "Inversion" > > t1<-Sys.time();for (i in 1:500) > ttt<-runif(100);print(Sys.time()-t1); > Time difference of 1.752916 mins > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
Duncan Murdoch wrote:
> On 8/29/2006 2:24 PM, Paul Gilbert wrote:
>
>> Seth Falcon wrote:
>>
>>> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>>>
>>>
On 8/29/2006 11:58 AM, Seth Falcon wrote:
> I think there is an important distinction between a dependency needed
> for the package to function and a dependency needed to demonstrate
> said functionality via an example or vignette. The former is what
> Depends is about, the latter is something else (Suggests).
>
Yes, that's a good point, especially with vignettes. Only the package
author needs to be able to run them.
>>>
>>>
>>> Yes, but just to keep things clear: the value of vignettes is that
>>> users can follow along. So the ability to programatically identify
>>> the extra required packages is valuable.
>>>
>>>
>>>
But maybe examples should be considered broken if they don't
work. Users should be able to expect example(foo) not to generate an
error. Package authors should wrap optional examples in code like if
(require(...)).
>>>
>> This is a work around that is ok for the developer's testing and to
>> prevent failure on CRAN, and I use it. But, other than actually
>> reading the examples, it provides no hints to other testers or users
>> about things that might be installed, or installed first, to give
>> more complete testing and more functionality.
>
>
> I'm not saying to use this instead of Suggests, I'm saying to do both.
> This way the Suggests entries really are suggestions: the examples
> will run with or without the presence of the suggested packages.
>
> I think there are so many variations on when a Suggested package
> should be installed, that it's not reasonable to expect to be able to
> encode them all in a machine readable way. They should be documented
> in human readable format.
>
>> Looking toward the future, I think it would be useful to have a
>> standard mechanism to indicate extensions that are available in a
>> package, and might be tested and used, but are not necessarily
>> available on CRAN. For instance, an example might access to a
>> purchased database or take advantage of a computer cluster. It seems
>> limiting to think that all testing that cannot be done on CRAN must
>> be done almost exclusively by the developer.
>
>
> If by "mechanism" you mean human-readable documentation, I agree with
> this.
Yes, I was think of human-readable and in a standard location, like a
field in the DESCRIPTION file. (You are thinking of fields in the
DESCRIPTION file as human-readable, are you not?)
Paul
>
> Duncan Murdoch
>
>>
>> Paul
>>
>>>
>>> I agree. As with vignettes, there is value in users being able to
>>> follow along and it would be nice to have a programatic way to
>>> identify extra package needed for fancy/involved/optional examples.
>>>
>>> Best,
>>>
>>> + seth
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>>
>>
>>
>> La version française suit le texte anglais.
>>
>>
>>
>>
>>
>> This email may contain privileged and/or confidential
>> inform...{{dropped}}
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'CanMakeUseOf' field
On 8/29/2006 4:13 PM, Paul Gilbert wrote:
>
> Duncan Murdoch wrote:
>
>> On 8/29/2006 2:24 PM, Paul Gilbert wrote:
>>
>>> Seth Falcon wrote:
>>>
Duncan Murdoch <[EMAIL PROTECTED]> writes:
> On 8/29/2006 11:58 AM, Seth Falcon wrote:
>
>
>> I think there is an important distinction between a dependency needed
>> for the package to function and a dependency needed to demonstrate
>> said functionality via an example or vignette. The former is what
>> Depends is about, the latter is something else (Suggests).
>>
>
> Yes, that's a good point, especially with vignettes. Only the package
> author needs to be able to run them.
>
Yes, but just to keep things clear: the value of vignettes is that
users can follow along. So the ability to programatically identify
the extra required packages is valuable.
> But maybe examples should be considered broken if they don't
> work. Users should be able to expect example(foo) not to generate an
> error. Package authors should wrap optional examples in code like if
> (require(...)).
>
>>> This is a work around that is ok for the developer's testing and to
>>> prevent failure on CRAN, and I use it. But, other than actually
>>> reading the examples, it provides no hints to other testers or users
>>> about things that might be installed, or installed first, to give
>>> more complete testing and more functionality.
>>
>>
>> I'm not saying to use this instead of Suggests, I'm saying to do both.
>> This way the Suggests entries really are suggestions: the examples
>> will run with or without the presence of the suggested packages.
>>
>> I think there are so many variations on when a Suggested package
>> should be installed, that it's not reasonable to expect to be able to
>> encode them all in a machine readable way. They should be documented
>> in human readable format.
>>
>>> Looking toward the future, I think it would be useful to have a
>>> standard mechanism to indicate extensions that are available in a
>>> package, and might be tested and used, but are not necessarily
>>> available on CRAN. For instance, an example might access to a
>>> purchased database or take advantage of a computer cluster. It seems
>>> limiting to think that all testing that cannot be done on CRAN must
>>> be done almost exclusively by the developer.
>>
>>
>> If by "mechanism" you mean human-readable documentation, I agree with
>> this.
>
> Yes, I was think of human-readable and in a standard location, like a
> field in the DESCRIPTION file. (You are thinking of fields in the
> DESCRIPTION file as human-readable, are you not?)
Yes, but I don't think that's necessarily the right place for this.
What we were going to do this summer was to make it easier to build
foo-package.Rd files, without duplication of the information in the
DESCRIPTION file. I think that man page (or a man page linked from it)
would be the right place for a detailed discussion like this.
This doesn't address the problem of someone who hasn't got the package
installed yet, though perhaps CRAN could put a version of that man page
(or all of them) online for browsing. Unfortunately this hasn't
happened yet, but maybe we'll get to it before 2.5.0.
Duncan Murdoch
>
> Paul
>
>>
>> Duncan Murdoch
>>
>>>
>>> Paul
>>>
I agree. As with vignettes, there is value in users being able to
follow along and it would be nice to have a programatic way to
identify extra package needed for fancy/involved/optional examples.
Best,
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>>
>>>
>>> La version française suit le texte anglais.
>>>
>>>
>>>
>>>
>>>
>>> This email may contain privileged and/or confidential
>>> inform...{{dropped}}
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential info...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] list and pairlist in "Writing R Extensions" (PR#9185)
Full_Name: Glen Herrmannsfeldt
Version: 2.2.1
OS: Linux
Submission from: (NULL) (128.95.113.77)
Following the discussion in "Writing R Extensions" in section 5.8.2, there
is no indication that showArgs expects a pairlist() instead of a list().
I was trying
.Call("showArgs",list(one=1,two=2,three=3))
for example, and getting many core dumps.
It wasn't until reading "R Language Definition" that I found out
about pairlist(), as needed.
The final example:
showArgs<-function(...) .Call("showArgs1",list(...))
looks like a list can be passed to showArgs, but in fact it is showArgs1, which
doesn't seem to be documented at all!
It could be that using pairlist() in 5.8.2 would fix the problem,
but there should be a reference to the difference between list()
and pairlist()
thanks,
-- glen
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rgamma gives zeros. (PR#9184)
Full_Name: Peiyi Xi Version: R 2.2.0 OS: Windows XP Professional Submission from: (NULL) (128.2.3.141) When I use rgamma(n, shape, rate ) to generate gamma samples, it gives zeros when both shape and rate are very small. But we know that if x follows a gamma distribution, x should be positive. e.g. > temp=rgamma(10, 0.001, rate=0.01) > temp [1] 2.438078e-33 5.101136e-130 1.760830e-54 2.724731e-166 0.00e+00 [6] 4.461151e-146 1.332914e-55 2.336396e-277 0.00e+00 0.00e+00 > temp[5] [1] 0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list and pairlist in "Writing R Extensions" (PR#9185)
It says clearly that showArgs is for use by .External, not .Call (it is
introduced in a paragraph about the differences):
@example
showArgs <- function(...) .External("showArgs", ...)
@end example
and that is the main user error here. Pairlists are not needed when used
as documented.
On Wed, 30 Aug 2006, [EMAIL PROTECTED] wrote:
> Full_Name: Glen Herrmannsfeldt
> Version: 2.2.1
> OS: Linux
> Submission from: (NULL) (128.95.113.77)
>
>
> Following the discussion in "Writing R Extensions" in section 5.8.2, there
> is no indication that showArgs expects a pairlist() instead of a list().
>
> I was trying
>
> .Call("showArgs",list(one=1,two=2,three=3))
>
> for example, and getting many core dumps.
>
> It wasn't until reading "R Language Definition" that I found out
> about pairlist(), as needed.
> The final example:
>
> showArgs<-function(...) .Call("showArgs1",list(...))
>
> looks like a list can be passed to showArgs, but in fact it is showArgs1,
> which
> doesn't seem to be documented at all!
It says this is an 'alternative style', not an example.
> It could be that using pairlist() in 5.8.2 would fix the problem,
> but there should be a reference to the difference between list()
> and pairlist()
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
