[Rd] hasNA() / anyNA()?
Hi,
is there a hasNA() / an anyNA() function in R? Of course,
hasNA <- function(x) {
any(is.na(x));
}
would do, but that would scan all elements in 'x' and then do the
test. I'm looking for a more efficient implementation that returns
TRUE at the first NA, e.g.
hasNA <- function(x) {
for (kk in seq(along=x)) {
if (is.na(x[kk]))
return(TRUE);
}
FALSE;
}
Cheers
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hasNA() / anyNA()?
I don't know of one.
Ideally, instead of a specifc function anyNA() function, any() could be
perhaps be extended to any(x, FUN) where FUN returns a logical for an
element of x, and implemented to find the 1st instance as you suggest.
Mike
On 8/13/07, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> is there a hasNA() / an anyNA() function in R? Of course,
>
> hasNA <- function(x) {
> any(is.na(x));
> }
>
> would do, but that would scan all elements in 'x' and then do the
> test. I'm looking for a more efficient implementation that returns
> TRUE at the first NA, e.g.
>
> hasNA <- function(x) {
> for (kk in seq(along=x)) {
> if (is.na(x[kk]))
> return(TRUE);
> }
> FALSE;
> }
>
> Cheers
>
> Henrik
>
> __
> 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
[Rd] Mistake in ISOLatin7.enc file (PR#9845)
Full_Name: Vaidotas Zemlys Version: 2.5.1 OS: Ubuntu 7.04 Submission from: (NULL) (213.197.173.50) Hi, There is a mistake in ISOLatin7.enc file which is shipped with grDevices package. Instead of Umacron and umacron there are Ucirmcumflex and ucirmcumflex. There is no U cirmcumflex in ISO Latin 7 encoding, as can be seen in http://en.wikipedia.org/wiki/ISO/IEC_8859-13 and I also can report this as native Lithuanian speaker, since ISO Latin 7 encoding is used for Lithuanian and Latvian languages. Steps to reproduce 1. In R issue commands : postscript(file="test.ps",encoding="ISOLatin7") plot(rnorm(100),main="Ūū") dev.off() When viewing postcript file instead of Ūū you will see Ûû. Changing [uU]circumflex to [uU]macron in file ISOLatin7.enc fixes the problem. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Non-administrator can't install packages (PR#9848)
Full_Name: Russ Lenth
Version: 1.5.1
OS: Windows XP Pro
Submission from: (NULL) (128.255.132.36)
I run a Windows system on which I do not have administrator rights. I am unable
to install R packages, even in a location that I have access to. I get a
message that it can't write to the specified directory. I know I WAS able to do
this last April (version 1.4.1??) on the same system -- I have several installed
packages to show for it.
Some R session excerpts are below. I have tried the same things on my laptop,
with no problems; thus, I think this bug is related to my not having
Administrator rights.
By the way, in each call to install.packages(), I get an offer to create a new
library directory, even though I have specified one explicitly in the "lib"
argument. That seems like a bug too.
My current workaround is to just download and unzip the file to that directory,
with R not running. That seems to work, but I'm not sure everything gets set up
properly that way.
= Attempt to install a package to my usual location on a network drive:
R> .libPaths()
[1] "h:/pkg/R/library" "C:/PROGRA~1/R/R-25~1.1/library"
R> install.packages( "odfWeave", lib="h:/pkg/R/library")
Warning in install.packages("d:/downloads/odfWeave_0.5.9.zip", lib =
"h:/pkg/R/library") :
'lib = "h:/pkg/R/library"' is not writable
Error in install.packages("d:/downloads/odfWeave_0.5.9.zip", lib =
"h:/pkg/R/library") :
unable to install packages
= Attempt to install to a local drive:
R> install.packages( "odfWeave", lib="d:")
Warning in install.packages("d:/downloads/odfWeave_0.5.9.zip", lib = "d:") :
'lib = "d:"' is not writable
Error in install.packages("d:/downloads/odfWeave_0.5.9.zip", lib = "d:") :
unable to install packages
= Yet, I can write to that location:
R> sink("h:/pkg/R/library/junk.txt")
R> ls()
R> sink()
R> system("cat h:/pkg/R/library/junk.txt")
[1] "align" "align.default" "align.lm"
[4] "align.old" "align.very.old" "augment"
.
R> system("rm h:/pkg/R/library/junk.txt")
R>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Change in grep functionality causes Rd_db to fail silently (PR#9846)
Full_Name: Mike Pacey
Version: 2.5.1
OS: SUSE SE Linux 9.3
Submission from: (NULL) (194.80.32.10)
Versions 2.5.0 and 2.5.1 currently fail "make check" on my system due to a
silent failure in the call to Rd_db("base"):
-
> ### Name: Rdutils
> ### Title: Rd Utilities
> ### Aliases: Rd_db Rd_parse
> ### Keywords: utilities documentation
>
> ### ** Examples
>
> ## Build the Rd db for the (installed) base package.
> db <- Rd_db("base")
> ## Run Rd_parse on all entries in the Rd db.
> db <- lapply(db, function(txt) Rd_parse(text = txt))
> ## Extract the metadata.
> meta <- lapply(db, "[[", "meta")
>
> ## Keyword metadata per Rd file.
> keywords <- lapply(meta, "[[", "keywords")
> ## Tabulate the keyword entries.
> kw_table <- sort(table(unlist(keywords)))
Error in as.vector(x, mode) : invalid argument 'mode'
Execution halted
Tracing through the call to Rd_db, a call is made to list_files_with_exts(). The
functionality of the relevant section of that function in 2.4.0 is replicated
here:
> dir
[1] "/usr/local/packages/R-2.4.0-acml/lib64/R/library/base/man"
> files <- list.files(dir)
> files
[1] "base.Rd.gz"
> patt
[1] "\\.(Rd|rd|Rd.gz|rd.gz)$"
> grep(patt, files, value = TRUE)
[1] "base.Rd.gz"
In 2.5.1, the behaviour of grep() seems to have changed:
> dir
[1] "/usr/local/packages/src/R-2.5.1/library/base/man"
> files <- list.files(dir)
> files
[1] "base.Rd.gz"
> patt
[1] "\\.(Rd|rd|Rd.gz|rd.gz)$"
> grep(patt, files, value = TRUE)
character(0)
The result is that the call to Rd_db fails to find the relevant documentation
for the base package.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hasNA() / anyNA()?
> Michael Cassin writes:
> I don't know of one.
> Ideally, instead of a specifc function anyNA() function, any() could
> be perhaps be extended to any(x, FUN) where FUN returns a logical for
> an element of x, and implemented to find the 1st instance as you
> suggest.
Patterned after Common Lisp's position(), ideally we would have formals
(x, FUN, right = FALSE) where the last argument controls whether the
search proceeds from left to right or right to left.
This would certainly be very nice to have, and make it trivial to
provide an efficient variant of Common Lisp's find() (which finds the
first element from the left or right for which the predicate gives
true).
-k
> Mike
> On 8/13/07, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> is there a hasNA() / an anyNA() function in R? Of course,
>>
>> hasNA <- function(x) {
>> any(is.na(x));
>> }
>>
>> would do, but that would scan all elements in 'x' and then do the
>> test. I'm looking for a more efficient implementation that returns
>> TRUE at the first NA, e.g.
>>
>> hasNA <- function(x) {
>> for (kk in seq(along=x)) {
>> if (is.na(x[kk]))
>> return(TRUE);
>> }
>> FALSE;
>> }
>>
>> Cheers
>>
>> Henrik
>>
>> __
>> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Compilation error with R-devel_2007-08-12.tar.gz snapshot
Hi, I get a compilation error with last available R devel snapshot (R-devel_2007-08-12.tar.gz, r42483): CONFIGURE [EMAIL PROTECTED]:~/R-2.6.broken> ~/src/R-2.6.r42483/configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu [...] R is now configured for x86_64-unknown-linux-gnu Source directory: /home/hpages/src/R-2.6.r42483 Installation directory:/usr/local C compiler:gcc -std=gnu99 -g -O2 Fortran 77 compiler: gfortran -g -O2 C++ compiler: g++ -g -O2 Fortran 90/95 compiler:gfortran -g -O2 Obj-C compiler:gcc -g -O2 Interfaces supported: X11, tcltk External libraries:readline Additional capabilities: PNG, JPEG, iconv, MBCS, NLS Options enabled: shared BLAS, R profiling, Java Recommended packages: yes == MAKE === [EMAIL PROTECTED]:~/R-2.6.broken> make [...] make[1]: Entering directory `/home/hpages/R-2.6.broken/src/library/Recommended' make[2]: Entering directory `/home/hpages/R-2.6.broken/src/library/Recommended' make[2]: *** No rule to make target `VR.ts', needed by `stamp-recommended'. Stop. make[2]: Leaving directory `/home/hpages/R-2.6.broken/src/library/Recommended' make[1]: *** [recommended-packages] Error 2 make[1]: Leaving directory `/home/hpages/R-2.6.broken/src/library/Recommended' make: *** [stamp-recommended] Error 2 I have no problems with older tarballs e.g. tarball from 2007-08-06 (r42439) compiles fine. Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [Fwd: behavior of L-BFGS-B with trivial function triggers bug in stats4::mle]
I sent this in first on 30 July. Now that UseR! is over I'm trying again
(slightly extended version from last time).
With R 2.5.1 or R 2.6.0 (2007-08-04 r42421)
"L-BFGS-B" behaves differently from all of the
other optim() methods, which return the value of the function
when they are given a trivial function (i.e., one with no
variable arguments) to optimize. This is not
a bug in L-BFGS-B (more like a response to
an undefined condition), but it leads to a bug in stats4::mle --
a spurious error saying that a better fit
has been found during profiling if one tries to profile
a 1-parameter model that was originally fitted with "L-BFGS-B".
One possible fix is to check for length(start)==0 and
return a dummy optim() result in that case (see patch included below).
The patch below fixes the basic problem, although I haven't
tested extensively to see what its other implications are.
Or one could change L-BFGS-B to behave the same as the other methods.
If I don't hear anything in a few days would it be appropriate
to submit this as a bug report?
cheers
Ben Bolker
-
library(stats4)
## using example from ?mle
x <- 0:10
y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8)
ll <- function(ymax=15, xhalf=6)
-sum(stats::dpois(y, lambda=ymax/(1+x/xhalf), log=TRUE))
## fix one parameter to get 1D profile
fit2 <- mle(ll, fixed=list(xhalf=6))
profile(fit2)
## same again with method="L-BFGS-B"
fit3 <- mle(ll, fixed=list(xhalf=6),method="L-BFGS-B")
profile(fit3) ## BUG
ll0 <- function(zzz) {
ymax <- 15
xhalf <- 6
-sum(stats::dpois(y, lambda=ymax/(1+x/xhalf), log=TRUE))
}
## try mle() with all-fixed parameters with various methods ...
methods = eval(formals(optim)$method)
sapply(methods,
function(m) {
-logLik(mle(ll, start=list(ymax=15,xhalf=6),
fixed=list(ymax=15,xhalf=6),method=m))
})
## Nelder-Mead BFGSCG L-BFGS-B SANN
## 3.389441e+01 3.389441e+01 3.389441e+01 5.048277e-270 3.389441e+01
*** mle.R 2007-07-27 11:50:38.0 -0400
--- src/library/stats4/R/mle.R 2007-08-13 17:47:11.0 -0400
***
*** 56,62
l[n] <- fixed
do.call("minuslogl", l)
}
! oout <- optim(start, f, method=method, hessian=TRUE, ...)
coef <- oout$par
vcov <- if(length(coef)) solve(oout$hessian) else matrix(numeric(0),0,0)
min <- oout$value
--- 56,66
l[n] <- fixed
do.call("minuslogl", l)
}
! if (length(start)==0) {
!oout <- list(par=numeric(0),value=f(start))
! } else {
! oout <- optim(start, f, method=method, hessian=TRUE, ...)
! }
coef <- oout$par
vcov <- if(length(coef)) solve(oout$hessian) else matrix(numeric(0),0,0)
min <- oout$value
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compilation error with R-devel_2007-08-12.tar.gz snapshot
Problem gone with new snapshot (2007-08-13, r42496). Thanks! H. Herve Pages wrote: > Hi, > > I get a compilation error with last available R devel > snapshot (R-devel_2007-08-12.tar.gz, r42483): > > > CONFIGURE > > [EMAIL PROTECTED]:~/R-2.6.broken> ~/src/R-2.6.r42483/configure > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > [...] > R is now configured for x86_64-unknown-linux-gnu > > Source directory: /home/hpages/src/R-2.6.r42483 > Installation directory:/usr/local > > C compiler:gcc -std=gnu99 -g -O2 > Fortran 77 compiler: gfortran -g -O2 > > C++ compiler: g++ -g -O2 > Fortran 90/95 compiler:gfortran -g -O2 > Obj-C compiler:gcc -g -O2 > > Interfaces supported: X11, tcltk > External libraries:readline > Additional capabilities: PNG, JPEG, iconv, MBCS, NLS > Options enabled: shared BLAS, R profiling, Java > > Recommended packages: yes > > > == MAKE === > > [EMAIL PROTECTED]:~/R-2.6.broken> make > [...] > make[1]: Entering directory > `/home/hpages/R-2.6.broken/src/library/Recommended' > make[2]: Entering directory > `/home/hpages/R-2.6.broken/src/library/Recommended' > make[2]: *** No rule to make target `VR.ts', needed by `stamp-recommended'. > Stop. > make[2]: Leaving directory `/home/hpages/R-2.6.broken/src/library/Recommended' > make[1]: *** [recommended-packages] Error 2 > make[1]: Leaving directory `/home/hpages/R-2.6.broken/src/library/Recommended' > make: *** [stamp-recommended] Error 2 > > > I have no problems with older tarballs e.g. tarball from 2007-08-06 (r42439) > compiles fine. > > Cheers, > H. > > __ > 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] Change of compiler for Windows build of R
The MinGW people have finally released a couple of builds of gcc 4.2.1 (and finally moved the build of 3.4.5 to release status after 19 months as 'candidate'). We intend to use gcc 4.2.1 for the binary distribution of R 2.6.0, and builds of R-devel are being made with it from now on. The R-admin manual now contains details of the pieces you need, and in due course there will be an updated Rtools.exe containing this version. I've successfully built cross-compilers although am unlikely to distribute one for a while. gcc 4.2.1 is a better check of standards conformance, and you may see warnings in packages not present with gcc 3.4.5. All the CRAN packages have been checked, and this showed up some issues with packages which deviated markedly from the documented procedures. E.g. - the C++ compiler is $(CXX), not g++, and $(CXX) is defined in MkRules. - there is a quirk with dlltool both on Vista and with gcc 4.2.1 on XP that needs '--as' included amongst the flags. The rule in MkRules works: several user-written rules do not. So far we have seen no issues with mixing code compiled with gcc 3.4.5 and 4.2.1. There would almost certainly be issues with third-party C++ libraries, and might be some with Fortran libraries that use complex numbers. The advantages of using this port include: - Vista compatibility out of the box. - ongoing support. The main MinGW developer is really targetting gcc 4.3.0, and these compilers are interim releases with patches backported from the gcc trunk. - More complete C99 features: for example C99 inlining will be supported in gcc 4.3.0 (and has already been tested using snapshots). - integrated F9x support. F9x is supported 'out of the box', and can now consider using F9x code in R. - OMP and threading support. R 2.5.1 will not build out of the box with these compilers, but R-patched will (for suitable settings in MkRules). -- 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
