[Rd] data.matrix returns mode logical for zero rows (PR#8496)
Full_Name: Jonathan Swinton Version: 2.2.1 OS: Windows Submission from: (NULL) (193.132.159.169) #The first line of description for data.matrix says that it will # 'Return the matrix obtained by converting all the variables in a #data frame to numeric mode and then binding them together as the # columns of a matrix.' #However when called with a data.frame with zero rows, data.matrix returns a matrix #of mode logical rather than numeric. This conflicts with the documentation #and is not what seems sensible. # One underlying reason for this is that when a zero-length column of a matrix of mode logical is # asserted to be numeric the matrix is not actually cast to numeric. I wonder if that too is a bug? > R.version.string [1] "R version 2.2.1, 2005-12-20" > df <- data.frame(matrix(1:2,nrow=2)) > mode(data.matrix(df)[,1]) [1] "numeric" > mode(data.matrix(df[FALSE,])[,1]) [1] "numeric" > > # Underlying cause > x <- matrix(nr = 2,nc = 1 ) > mode(x) [1] "logical" > x[, 1] <- c(1,2) > mode(x) [1] "numeric" > > x0 <- matrix(nr = 0, nc = 1) > x0[, 1] <- numeric(0) > mode(x0) [1] "logical" > mode(x0[,1]) [1] "logical" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Section 7.1 HML documentation (PR#8484)
[EMAIL PROTECTED] wrote: > Full_Name: Greg Kochanski > Version: 2.2.0 > OS: Debian Linux i686 > Submission from: (NULL) (212.159.16.190) > > > In /usr/share/doc/r-doc-html/manual/R-data.html (at least that's where > it is on Debian...) the documentation is unclear. Comments below. The documentation is, I believe, correct and precise as it stands. What it doesn't emphasize and mention is the difference between "BSD socket" and "socket connection", or an "R connection of the socket type". And it is recommended that you use "socket connection" instead of "BSD socket". The earlier "BSD socket" is created, read, write with "make.socket"/"read.socket"/"write socket"/"close socket". The newer "socket connection" is created by creating a new connection object like this: con <- socketConnection(port = 79, blocking = TRUE) and invoking the open/write/read method of the "connection" object. type "?connection" in an R prompt for details. "BSD socket" is a unix concept, "socket connection" is an R object. The paragraph should have put "BSD socket" and "socket connection" in quote or italics. Make more sense? Somebody please fix the paragraph... :-). > The paragraph has unclear references, and I have no idea what > it actually means. > > >>>Base R comes with some facilities to communicate via BSD sockets on systems > > that support them (...). One potential problem > >>>For new projects it is suggested that socket connections are used instead. > > > "Used instead"? Instead of what? > > >>>The earlier low-level interface is given by functions make.socket, > > read.socket, write.socket and close.socket. > > What does "earlier" mean? Earlier than what? > > __ > 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] Section 7.1 HML documentation (PR#8484)
Well, I don't know how it can be precise and correct when it has dangling antecedents. Gramatically speaking, that's the equivalent of an uninitialized pointer. However, I agree with you that it probably just needs a minor bit of fiddling to make sure it answers "Instead of what?" and "Earlier than what?" Hin-Tak Leung wrote: > [EMAIL PROTECTED] wrote: > >> Full_Name: Greg Kochanski >> Version: 2.2.0 >> OS: Debian Linux i686 >> Submission from: (NULL) (212.159.16.190) >> >> >> In /usr/share/doc/r-doc-html/manual/R-data.html (at least that's where >> it is on Debian...) the documentation is unclear. Comments below. > > > The documentation is, I believe, correct and precise as it stands. > What it doesn't emphasize and mention is the difference between > "BSD socket" and "socket connection", or an "R connection of the socket > type". And it is recommended that you > use "socket connection" instead of "BSD socket". > > The earlier "BSD socket" is created, read, write with > "make.socket"/"read.socket"/"write socket"/"close socket". > > The newer "socket connection" is created by creating a new connection > object like this: > con <- socketConnection(port = 79, blocking = TRUE) > and invoking the open/write/read method of the "connection" > object. type "?connection" in an R prompt for details. > > "BSD socket" is a unix concept, "socket connection" is an R object. > The paragraph should have put "BSD socket" and "socket connection" > in quote or italics. Make more sense? > > Somebody please fix the paragraph... :-). > >> The paragraph has unclear references, and I have no idea what >> it actually means. >> >> Base R comes with some facilities to communicate via BSD sockets on systems >> >> >> that support them (...). One potential problem >> For new projects it is suggested that socket connections are used instead. >> >> >> >> "Used instead"? Instead of what? >> >> The earlier low-level interface is given by functions make.socket, >> >> >> read.socket, write.socket and close.socket. >> What does "earlier" mean? Earlier than what? >> >> __ >> 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] CRAN mirror at StatLib
Dear Pantelis, there have been numerous reports on the R mailing lists that the StatLib mirror of CRAN is not up to date, and I also have written several emails to you asking about the nature of the problems. E.g., http://lib.stat.cmu.edu/R/CRAN/bin/windows/contrib/ shows an old listing, and http://lib.stat.cmu.edu/R/CRAN/bin/windows/contrib/r-release/ points to the wrong directory giving packages for the development version of R rather then the released version (on the master it is a link to 2.2, on your copy it seems to be a link to 2.3). If the problems persist and cannot be fixed it is perhaps the easiest solution if you stop mirroring CRAN, as download problems from StatLib get reported to us as "bugs in R". With best regards, Fritz Leisch -- --- Friedrich Leisch Institut für Statistik Tel: (+43 1) 58801 10715 Technische Universität WienFax: (+43 1) 58801 10798 Wiedner Hauptstraße 8-10/1071 A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [OT] GPL3 draft
Since someone is bound to point this out soon I will note that a) A discussion draft of the proposed GPL version 3 is up at http://gplv3.fsf.org/ b) If you have comments on the draft, send them to the FSF rather than to r-devel -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] natural sorting
The 'mixedsort' function in the 'gtools' package does this. It is probably
slower than the c version you point to, but it is already working in R.
-G
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Andrew Piskorski
> Sent: Thursday, January 12, 2006 10:40 AM
> To: R Development Mailing List
> Subject: Re: [Rd] natural sorting
>
>
> On Wed, Jan 11, 2006 at 05:45:10PM -0500, Gabor Grothendieck wrote:
> > It would be nifty to incorporate this into R or into an R package:
> >
> > http://sourcefrog.net/projects/natsort/
>
> Btw, I haven't looked at the implementation, but Tcl also contains
> equivalent functionality, they call it dictionary sort:
>
> http://tcl.activestate.com/man/tcl8.4/TclCmd/lsort.htm
>
> --
> Andrew Piskorski <[EMAIL PROTECTED]>
> http://www.piskorski.com/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nls profile with port/constraints
Sorry to report further difficulties with
nls and profiling and constraints ... the problem
this time (which I didn't check for in my last
round of testing) is that the nls profiler doesn't
seem to respect constraints that have been
set when using the port algorithm.
See test code below ...
If I can I will try to hack the code, but I will
probably start by redefining my function with
some workarounds to make the fit quadratically "bad" (but well-defined)
when the parameters are negative ...
As always, please don't hesitate to correct me
if I'm being an idiot ...
cheers
Ben Bolker
---
rm(list=ls())
npts=10
set.seed(1001)
a =2
b =0.5
x= runif(npts)
y = a*x/(1+a*b*x)+rnorm(npts,sd=0.2)
gfun <- function(a,b,x) {
if (a<0 || b<0) stop("bounds violated")
a*x/(1+a*b*x)
}
m1 = nls(y~gfun(a,b,x),algorithm="port",
lower=c(0,0),start=c(a=1,b=1))
try(confint(m1))
for what it's worth, the logic appears to be OK in mle in the stats4
library:
--
library(stats4)
mfun <- function(a,b,s) {
if (a<0 || b<0 || s<0) stop("bounds violated")
-sum(dnorm(y,a*x/(1+a*b*x),sd=s,log=TRUE))
}
m2 = mle(minuslogl=mfun,
start=list(a=1,b=1,s=0.1),
method="L-BFGS-B",lower=c(0.002,0.002,0.002))
confint(m2)
m2b = mle(minuslogl=mfun,
fixed=list(b=0),start=list(a=1,s=0.1),
method="L-BFGS-B",lower=c(0.002,0.002,0.002))
## set boundary slightly above zero to avoid
## boundary cases
dev <- 2*(-logLik(m2b)+logLik(m2))
as.numeric(pchisq(dev,lower.tail=FALSE,df=1))
--
620B Bartram Hall[EMAIL PROTECTED]
Zoology Department, University of Floridahttp://www.zoo.ufl.edu/bolker
Box 118525 (ph) 352-392-5697
Gainesville, FL 32611-8525 (fax) 352-392-3704
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
