Re: [Rd] c(, ) / help(dotsMethods) etc
> Martin Maechler
> on Sat, 10 Sep 2016 21:49:37 +0200 writes:
> John Chambers
> on Sat, 10 Sep 2016 09:16:38 -0700 writes:
>> (Brief reply, I'm traveling but as per below, this is on my radar right
now so wanted to comment.)
>> Two points regarding "dotsMethods".
>> 1. To clarify the limitation. It's not that all the arguments have to
be of the same class, but there must be one class that they belong to or
subclass. (So, as in the example in the documentation, the method could be
defined for a class union or other virtual class that all the actual arguments
inherit from.)
> Thank you for the clarification.
> I knew that the limitation "the same class" has not been a big
> one, that's why I did use a class union in my example (below).
> I thought there were other limitations.. never mind.
>> 2. The current documentation is a mess. In common with lots of other
very old documentation. I'm in the process of rewriting a large chunk of the
documentation including that for dotsMethods. Sometime in the next few weeks,
I hope to have it coherent enough to commit.
> That's great!
>> So far, I'm not trying to change any significant aspects of the code,
including for "..." methods, which seem to do roughly what was intended.
> Yes, I'm sorry if I sounded like saying something different.
> That I think this [getting c() to work for a collection objects,
> some S4] needs changes in R is because it seems that do_c()
> fails to dispatch here, and hence the problem was with our C
> function that has carried the comment
> | * To call this an ugly hack would be to insult all existing ugly hacks
> | * at large in the world.
> and I don't think I would be able to correctly patch that
> infamous function (in src/main/eval.c) ...
> Martin
On the other hand,
with the following patch
--- bind.c (revision 71239)
+++ bind.c (working copy)
@@ -732,7 +732,8 @@
/* Attempt method dispatch. */
-if (DispatchOrEval(call, op, "c", args, env, &ans, 1, 1))
+if (DispatchAnyOrEval(call, op, "c", args, env, &ans, 1, 1))
+ // ^^^ "Any" => all args are eval()ed and checked => correct
multi-arg dispatch
return(ans);
PROTECT(ans);
SEXP res = do_c_dflt(call, op, ans, env);
the problem is basically solved.
Yes it does cost a tiny bit: according to minimal example testing (and
microbenchmark):
d4 <- diag(4); microbenchmark(c(), c(1), c(2,3), c(d4,3:1), times=2^12)
it costs 10-20 nanoseconds per call .. and possibly slightly
more after attaching a version of 'Matrix' with new 'c' methods,
where all versions of
c(..., , ...)
would work.
OTOH, it seems very natural to me to allow proper dispatch once
a
setMethod("c", "numMatrixLike", function(x, ..., recursive) { ...})
or even a
setMethod("c", "ANY", function(x, ..., recursive) { ...})
method is defined.
>> On Sep 10, 2016, at 8:27 AM, Martin Maechler
wrote:
>>> I have been asked (by Roger; thank you for the good question,
>>> and I hope it's fine to answer to the public) :
>>>
with Pi a sparse matrix and x,y, and ones
compatible n-vectors — when I do:
>>>
> c(t(x) %*% Pi %*% ones, t(ones) %*% Pi %*% y )
[[1]] 1 x 1 Matrix of class "dgeMatrix"
[,1] [1,]
0.1338527
[[2]] 1 x 1 Matrix of class "dgeMatrix"
>>> [,1] [1,]
0.7810341
>>>
I get a list whereas if Pi is an ordinary matrix I get a
vector. Is this intentional?
>>>
>>> Well, no. But it has been "unavoidable" in the sense that it had not
>>> been possible to provide S4 methods for '...' in the "remote"
>>> past, when Matrix was created.
>>>
>>> Later ... also quite a few years ago, John Chambers had added
>>> that possibility, with still some limitation (all '...' must be
>>> of the same class), and also plans to remove some of the
>>> limitations, see ?dotsMethods in R.
>>>
>>> I honestly have forgotten the history of my trying to provide 'c'
>>> methods for our "Matrix" objects after the 'dotsMethods'
>>> possibility had emerged, but I know I tried and had not seen a
>>> way to succeed "satisfactorily",
>>> but maybe I now think I maybe should try again.
>>> I currently think this needs changes to R before it can be done
>>> satisfactorily, and this is the main reason why this is a public
>>> answer to R-devel@..., but I'm happy if I'am wrong.
>>>
>>> The real challenge here is that I think that if it should "work",
>>> it should work so in all cases, e.g., also for
>>>
>>> c(NA, 3:2, Matrix(2:1), matrix(10:11))
>>>
>>> and that's not so easy, e.g., the following class and method
>>> definitions do *not* achieve the desired result:
>>>
>>> ## "mMatrix" is already hidden in
Re: [Rd] R-intro: function 'stderr' and 'sd'
> Suharto Anggono Suharto Anggono via R-devel
> on Fri, 9 Sep 2016 16:52:01 + writes:
> In "An Introduction to R" Version 3.3.1, in "4.2 The function tapply()
and ragged arrays", after
> stderr <- function(x) sqrt(var(x)/length(x)) ,
> there is a note in brackets:
> Writing functions will be considered later in [Writing your own
functions], and in this case was unnecessary as R also has a builtin function
sd().
> The part "in this case was unnecessary as R also has a builtin function
sd()" is misleading. The builtin function sd() doesn't calculate standard error
of the mean. It calculates standard deviation. The function 'stderr' can use
'sd':
> function(x) sd(x)/sqrt(length(x))
You are right; thank you Suharto.
It now says
(Writing functions will be considered later in @ref{Writing your own
functions}. Note that @R{}'s a builtin function @code{sd()} is something
different.)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-intro: function 'stderr' and 'sd'
While you are editing that, you might change its name from 'stderr'
to standardError (or standard_error, etc.) so as not to conflict with
base::stderr().
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Tue, Sep 13, 2016 at 8:55 AM, Martin Maechler wrote:
> > Suharto Anggono Suharto Anggono via R-devel
> > on Fri, 9 Sep 2016 16:52:01 + writes:
>
> > In "An Introduction to R" Version 3.3.1, in "4.2 The function
> tapply() and ragged arrays", after
> > stderr <- function(x) sqrt(var(x)/length(x)) ,
> > there is a note in brackets:
> > Writing functions will be considered later in [Writing your own
> functions], and in this case was unnecessary as R also has a builtin
> function sd().
>
> > The part "in this case was unnecessary as R also has a builtin
> function sd()" is misleading. The builtin function sd() doesn't calculate
> standard error of the mean. It calculates standard deviation. The function
> 'stderr' can use 'sd':
> > function(x) sd(x)/sqrt(length(x))
>
> You are right; thank you Suharto.
> It now says
>
> (Writing functions will be considered later in @ref{Writing your own
> functions}. Note that @R{}'s a builtin function @code{sd()} is something
> different.)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Coercion of 'exclude' in function 'factor' (was 'droplevels' inappropriate change)
> Suharto Anggono Suharto Anggono via R-devel
> on Fri, 2 Sep 2016 16:10:00 + writes:
> I am basically fine with the change.
> How about using just the following?
> if(!is.character(exclude))
> exclude <- as.vector(exclude, typeof(x)) # may result in NA
> x <- as.character(x)
> It looks simpler and is, more or less, equivalent.
yes, but the current code should be slightly faster..
> In factor.Rd, in description of argument 'exclude', "(when \code{x} is a
\code{factor} already)" can be removed.
> A larger change that, I think, is reasonable is entirely removing the code
> exclude <- as.vector(exclude, typeof(x)) # may result in NA
> The explicit coercion of 'exclude' is not necessary.
> Function 'factor' works without it.
> The coercion of 'exclude' may lead to a surprise because it "may result
in NA".
> Example from https://stat.ethz.ch/pipermail/r-help/2005-April/069053.html
:
>factor(as.integer(c(1,2,3,3,NA)), exclude=NaN)
> excludes NA.
> As a bonus, without the coercion of 'exclude', 'exclude' can be a factor
if 'x' is a factor. This part of an example in
https://stat.ethz.ch/pipermail/r-help/2011-April/276274.html works.
> cc <- c("x","y","NA")
> ff <- factor(cc)
> factor(ff,exclude=ff[3])
Yes, two good reasons for a change. factor() would finally
behave according to the documentation which has been mentioning
that 'exclude' could be a factor: ((Until my R-devel changes of a
few weeks ago, i.e. at least in all recent released versions of R)),
the help page for factor has said
|| If 'exclude' is used it should either be a factor with the same
|| level set as 'x' or a set of codes for the levels to be excluded.
> However, the coercion of 'exclude' has been in function 'factor' in R
"forever".
Indeed: On March 6, 1998, svn rev. 845, when the R source files got a
'.R' appended, and quite a long time before R 1.0.0,
the factor function was as short as (but using an .Internal(.) !)
function (x, levels = sort(unique(x), na.last = TRUE), labels, exclude = NA,
ordered = FALSE)
{
if (length(x) == 0)
return(character(0))
exclude <- as.vector(exclude, typeof(x))
levels <- levels[is.na(match(levels, exclude))]
x <- .Internal(factor(match(x, levels), length(levels),
ordered))
if (missing(labels))
levels(x) <- levels
else levels(x) <- labels
x
}
and already contained that line.
Nevertheless, simplifying factor() by removing that line (or those
2 lines, now!) seems to only have advantages
I'm not yet committing to anything, but currently would strongly
consider it .. though *after* the
' OP '
issue has settled a bit.
Martin
>
> On Wed, 31/8/16, Martin Maechler wrote:
> Subject: Re: [Rd] 'droplevels' inappropriate change
> Cc: "Martin Maechler"
> Date: Wednesday, 31 August, 2016, 2:51 PM
> Martin Maechler
> on Sat, 27 Aug 2016 18:55:37 +0200 writes:
> Suharto Anggono Suharto Anggono via R-devel
> on Sat, 27 Aug 2016 03:17:32 + writes:
>>> In R devel r71157, 'droplevels' documentation, in "Arguments" section,
says this about argument 'exclude'.
>>> passed to factor(); factor levels which should be excluded from the
result even if present. Note that this was implicitly NA in R <= 3.3.1 which
did drop NA levels even when present in x, contrary to the documentation. The
current default is compatible with x[ , drop=FALSE].
>>> The part
>>> x[ , drop=FALSE]
>>> should be
>>> x[ , drop=TRUE]
> [[elided Yahoo spam]]
>> a "typo" by me. .. fixed now.
>>> Saying that 'exclude' is factor levels is not quite true for NA
element. NA may be not an original level, but NA in 'exclude' affects the
result.
>>> For a factor 'x', factor(x, exclude = exclude) doesn't really work for
excluding in general. See, for example,
https://stat.ethz.ch/pipermail/r-help/2005-September/079336.html .
>>> factor(factor(c("a","b","c")), exclude="c")
>>> However, this excludes "2":
>>> factor(factor(2:3), exclude=2)
>>> Rather unexpectedly, this excludes NA:
>>> factor(factor(c("a",NA), exclude=NULL), exclude="c")
>>> For a factor 'x', factor(x, exclude = exclude) can only exclude
integer-like or NA levels. An explanation is in
https://stat.ethz.ch/pipermail/r-help/2011-April/276274.html .
>> Well, Peter Dalgaard (in that R-devel e-mail, a bit more than 5
>> years ago) is confirming the problem there, and suggesting (as
>> you, right?) that actually `factor()` is not behaving
>> correctly here.
>> And your persistence is finally getting close to convince me
>> that it is not just droplevels(), but factor() itself which
>> needs care here.
>> Interestingly, the followi
Re: [Rd] R-intro: function 'stderr' and 'sd'
> William Dunlap
> on Tue, 13 Sep 2016 09:06:00 -0700 writes:
> While you are editing that, you might change its name from 'stderr'
> to standardError (or standard_error, etc.) so as not to conflict with
> base::stderr().
oh yes.. blush! ..
Martin
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
> On Tue, Sep 13, 2016 at 8:55 AM, Martin Maechler
> wrote:
>> > Suharto Anggono Suharto Anggono via R-devel
>> > on Fri, 9 Sep 2016 16:52:01 + writes:
>>
>> > In "An Introduction to R" Version 3.3.1, in "4.2 The function
>> tapply() and ragged arrays", after
>> > stderr <- function(x) sqrt(var(x)/length(x)) ,
>> > there is a note in brackets:
>> > Writing functions will be considered later in [Writing your own
>> functions], and in this case was unnecessary as R also has a builtin
>> function sd().
>>
>> > The part "in this case was unnecessary as R also has a builtin
>> function sd()" is misleading. The builtin function sd() doesn't calculate
>> standard error of the mean. It calculates standard deviation. The
function
>> 'stderr' can use 'sd':
>> > function(x) sd(x)/sqrt(length(x))
>>
>> You are right; thank you Suharto.
>> It now says
>>
>> (Writing functions will be considered later in @ref{Writing your own
>> functions}. Note that @R{}'s a builtin function @code{sd()} is something
>> different.)
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> [[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
