Re: [Rd] median and data frames
I also favor deprecating mean.data.frame.
One possible exception would be for a single-column data frame.
But even here I'd say no, lest people expect the same behavior for
median, var, ...
Pat's suggestion of using stop() would work nicely for mean.
(but omit paste - stop handles that).
Tim Hesterberg
If Martin's proposal is accepted, does
that mean that the median method for
data frames would be something like:
function (x, ...)
{
stop(paste(you probably mean to use the command: sapply(,
deparse(substitute(x)), , median), sep=))
}
Pat
On 29/04/2011 15:25, Martin Maechler wrote:
Paul Johnsonpauljoh...@gmail.com
on Thu, 28 Apr 2011 00:20:27 -0500 writes:
On Wed, Apr 27, 2011 at 12:44 PM, Patrick Burns
pbu...@pburns.seanet.com wrote:
Here are some data frames:
df3.2- data.frame(1:3, 7:9)
df4.2- data.frame(1:4, 7:10)
df3.3- data.frame(1:3, 7:9, 10:12)
df4.3- data.frame(1:4, 7:10, 10:13)
df3.4- data.frame(1:3, 7:9, 10:12, 15:17)
df4.4- data.frame(1:4, 7:10, 10:13, 15:18)
Now here are some commands and their answers:
median(df4.4)
[1] 8.5 11.5
median(df3.2[c(1,2,3),])
[1] 2 8
median(df3.2[c(1,3,2),])
[1] 2 NA
Warning message:
In mean.default(X[[2L]], ...) :
argument is not numeric or logical: returning NA
The sessionInfo is below, but it looks
to me like the present behavior started
in 2.10.0.
Sometimes it gets the right answer. I'd
be grateful to hear how it does that -- I
can't figure it out.
Hello, Pat.
Nice poetry there! I think I have an actual answer, as opposed to
the
usual crap I spew.
I would agree if you said median.data.frame ought to be written to
work columnwise, similar to mean.data.frame.
apply and sapply always give the correct answer
apply(df3.3, 2, median)
X1.3 X7.9 X10.12
2 8 11
[...]
exactly
mean.data.frame is now implemented as
mean.data.frame- function(x, ...) sapply(x, mean, ...)
exactly.
My personal oppinion is that mean.data.frame() should never have
been written.
People should know, or learn, to use apply functions for such a
task.
The unfortunate fact that mean.data.frame() exists makes people
think that median.data.frame() should too,
and then
var.data.frame()
sd.data.frame()
mad.data.frame()
min.data.frame()
max.data.frame()
...
...
all just in order to *not* to have to know sapply()
No, rather not.
My vote is for deprecating mean.data.frame().
Martin
--
Patrick Burns
pbu...@pburns.seanet.com
twitter: @portfolioprobe
http://www.portfolioprobe.com/blog
http://www.burns-stat.com
(home of 'Some hints for the R beginner'
and 'The R Inferno')
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Kendall's tau code
I discovered that the Kendall's tau calculation in R uses all pairwise comparisons which is O(n^2) and takes a long time for large vectors. I implemented a O(n*log(n)) algorithm based on merge-sort. Is this of interest to be included in core R? The code (fortran and R wrapper) is available in my package clinfun v0.9.7 (not exported in NAMESPACE). Thanks, Venkat -- Venkatraman E. Seshan, Ph.D. | Attending Biostatistician Director of Biostatistics Computer-Intensive Support Services Department of Epidemiology and Biostatistics | MSKCC 307 E 63rd St 3rd Floor | New York, NY 10065 Phone: 646-735-8126 | Fax: 646-735-0010 = Please note that this e-mail and any files transmitted with it may be privileged, confidential, and protected from disclosure under applicable law. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this communication or any of its attachments is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting this message, any attachments, and all copies and backups from your computer. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Reference Classes: Accessing methods via [[...]], bug?
I've been trying to use methods for reference classes via the notation
[[...]] (X[[doSomething]] rather than X$doSomething), but it failed to
work. However, I did find that if you use the usual $ notation first,
[[...]] can be used afterwards. The following simple example illustrates the
point:
setRefClass(Number, + fields = list(+ value = numeric+ ),+
methods = list(+ addOne = function() {+ value - value + 1+ }+
)+ ) X - new(Number, value = 1) X[[value]][1] 1
X[[addOne]]()Error: attempt to apply non-function class(X[[addOne]]) #
NULL[1] NULL
class(X$addOne)[1] refMethodDefattr(,package)[1] methods
X[[addOne]]() X[[value]][1] 2 class(X[[addOne]])[1]
refMethodDefattr(,package)[1] methods
Is this a bug?
Chad Goymer
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Kendall's tau code
S == SeshanV sesh...@mskcc.org on Sat, 30 Apr 2011 11:20:59 -0400 writes: I discovered that the Kendall's tau calculation in R uses all pairwise comparisons which is O(n^2) and takes a long time for large vectors. I implemented a O(n*log(n)) algorithm based on merge-sort. Is this of interest to be included in core R? Yes, quite a bit of interest! I know about the O(n^2) feature for quite a while, and it is indeed a considerable problem in copula modelling which has become an interest of mine in the recent year. The code (fortran and R wrapper) is available in my package clinfun v0.9.7 (not exported in NAMESPACE). Thank you! Yes, I see you've put them there quite recently. I see the Fortran code uses modern allocate / deallocate constructs (that I don't know). As I think we'd want to use this in the C code which is also underlying cor(*, method=kendall) I'll eventually want a C version, not the least because we may look into dealing with NA 's in the same -- flexible -- way that they are handled currently via the 'use = ...' argument. I may contact you privately for more. Thanks again, Martin Maechler, ETH Zurich (and R Core Team). Thanks, Venkat -- Venkatraman E. Seshan, Ph.D. | Attending Biostatistician Director of Biostatistics Computer-Intensive Support Services Department of Epidemiology and Biostatistics | MSKCC 307 E 63rd St 3rd Floor | New York, NY 10065 Phone: 646-735-8126 | Fax: 646-735-0010 __ 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] Kendall's tau code
Feel free to contact me. Thanks, Venkat From: Martin Maechler [maech...@stat.math.ethz.ch] Sent: Saturday, April 30, 2011 5:05 PM To: Seshan, Venkatraman E./Epidemiology-Biostatistics Cc: r-devel@r-project.org Subject: Re: [Rd] Kendall's tau code S == SeshanV sesh...@mskcc.org on Sat, 30 Apr 2011 11:20:59 -0400 writes: I discovered that the Kendall's tau calculation in R uses all pairwise comparisons which is O(n^2) and takes a long time for large vectors. I implemented a O(n*log(n)) algorithm based on merge-sort. Is this of interest to be included in core R? Yes, quite a bit of interest! I know about the O(n^2) feature for quite a while, and it is indeed a considerable problem in copula modelling which has become an interest of mine in the recent year. The code (fortran and R wrapper) is available in my package clinfun v0.9.7 (not exported in NAMESPACE). Thank you! Yes, I see you've put them there quite recently. I see the Fortran code uses modern allocate / deallocate constructs (that I don't know). As I think we'd want to use this in the C code which is also underlying cor(*, method=kendall) I'll eventually want a C version, not the least because we may look into dealing with NA 's in the same -- flexible -- way that they are handled currently via the 'use = ...' argument. I may contact you privately for more. Thanks again, Martin Maechler, ETH Zurich (and R Core Team). Thanks, Venkat -- Venkatraman E. Seshan, Ph.D. | Attending Biostatistician Director of Biostatistics Computer-Intensive Support Services Department of Epidemiology and Biostatistics | MSKCC 307 E 63rd St 3rd Floor | New York, NY 10065 Phone: 646-735-8126 | Fax: 646-735-0010 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel = Please note that this e-mail and any files transmitted with it may be privileged, confidential, and protected from disclosure under applicable law. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this communication or any of its attachments is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and deleting this message, any attachments, and all copies and backups from your computer. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug report: R 2.14.0dev Sweave option width does not work
Hi! In R 2.14.0dev (R version 2.14.0 Under development (unstable) (2011-04-29 r55692), Windows release (http://cran.r-project.org/bin/windows/base/rdevel.html), the line : options(width=55) in code chunk of an Rnw file has no effect on sweave's output text file. The same thing in 2.13.0 worked. WBR, ALexander Favorov __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reference Classes: Accessing methods via [[...]], bug?
If this message is garbled for anyone else, the original question on
stackoverflow is here:
http://stackoverflow.com/questions/5841339/using-notation-for-reference-class-methods
Hadley
On Sat, Apr 30, 2011 at 11:35 AM, Chad Goymer chad.goy...@hotmail.co.uk wrote:
I've been trying to use methods for reference classes via the notation
[[...]] (X[[doSomething]] rather than X$doSomething), but it failed to
work. However, I did find that if you use the usual $ notation first,
[[...]] can be used afterwards. The following simple example illustrates
the point:
setRefClass(Number, + fields = list(+ value = numeric+ ),+
methods = list(+ addOne = function() {+ value - value + 1+
}+ )+ ) X - new(Number, value = 1) X[[value]][1] 1
X[[addOne]]()Error: attempt to apply non-function class(X[[addOne]]) #
NULL[1] NULL
class(X$addOne)[1] refMethodDefattr(,package)[1] methods
X[[addOne]]() X[[value]][1] 2 class(X[[addOne]])[1]
refMethodDefattr(,package)[1] methods
Is this a bug?
Chad Goymer
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
