[Rd] R CMD build and et_EE.UTF-8 locale -> invalid files (PR#10351)
Full_Name: Ott Toomet Version: 2.6.0, 2.5.x OS: debian etch, lenny Submission from: (NULL) (80.235.63.243) When building a package with 'R CMD build name_of_directory" using "et_EE.UTF-8" locale, I get the following: [EMAIL PROTECTED]:~/tyyq/econ/micEcon$ R CMD build trunk * checking for file 'trunk/DESCRIPTION' ... OK * preparing 'trunk': * checking DESCRIPTION meta-information ... OK * checking whether 'INDEX' is up-to-date ... NO * use '--force' to overwrite the existing 'INDEX' * removing junk files * excluding invalid files from 'micEcon' Subdirectory 'R' contains invalid file names: testConsist.R tobit2fit.R tobit2.R tobit5fit.R translogCalc.R translogDeriv.R translogEst.R translogHessian.R translogMonoRestr.R utils.R vcov-methods.R vcov.selection.R writeFront41in.R Subdirectory 'man' contains invalid file names: testConsist.Rd tobit2fit.Rd translogCalc.Rd translogDeriv.Rd translogEst.Rd translogHessian.Rd triang.Rd vcov-methods.Rd vcov.selection.Rd vecli2m.Rd veclipos.Rd vecli.Rd writeFront41in.Rd * checking for LF line-endings in source and make files * checking for empty or unneeded directories * building 'micEcon_0.3-8.tar.gz' Of course, the package does not work because of removal of these files. It is hard for me to see anything illegal in the listed file names. Even more, everything works perfectly, if I run the command from "C" locale: [EMAIL PROTECTED]:~/tyyq/econ/micEcon$ LC_ALL="C" R CMD build trunk * checking for file 'trunk/DESCRIPTION' ... OK * preparing 'trunk': * checking DESCRIPTION meta-information ... OK * checking whether 'INDEX' is up-to-date ... NO * use '--force' to overwrite the existing 'INDEX' * removing junk files * checking for LF line-endings in source and make files * checking for empty or unneeded directories * building 'micEcon_0.3-8.tar.gz' I can still can directly install from the subdirectory: 'R CMD INSTALL trunk' works well regardless of locale. The micEcon package is available at CRAN. Best, Ott __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dget not restoring dput in R 2.6.0 (PR#10350)
Full_Name: David States
Version: 2.6.0
OS: Windows XP64
Submission from: (NULL) (141.211.38.9)
# The pair of commands
#
# dput(object, "file.dput")
# object = dget("file.dput")
#
# should be a no op, but this is not working correctly for all objects.
#
# Simple example:
#
# make a simple object of class "hclust"
cl = hclust(dist(matrix(nrow=4,ncol=4, c(1:16
# save it to a file using dput
dput(cl, "cl.dput")
# the following two commands should give identical results, but they dont
str(cl)
str(dget("cl.dput"))
# plot also fails to interpret the labels on the restore object correctly
par(mfrow=c(2,1))
plot(cl)
plot(dget("cl.dput"))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build and et_EE.UTF-8 locale -> invalid files (PR#10351)
[EMAIL PROTECTED] wrote: > Full_Name: Ott Toomet > Version: 2.6.0, 2.5.x > OS: debian etch, lenny > Submission from: (NULL) (80.235.63.243) > > > When building a package with 'R CMD build name_of_directory" using > "et_EE.UTF-8" > locale, I get the following: > > [EMAIL PROTECTED]:~/tyyq/econ/micEcon$ R CMD build trunk > * checking for file 'trunk/DESCRIPTION' ... OK > * preparing 'trunk': > * checking DESCRIPTION meta-information ... OK > * checking whether 'INDEX' is up-to-date ... NO > * use '--force' to overwrite the existing 'INDEX' > * removing junk files > * excluding invalid files from 'micEcon' > Subdirectory 'R' contains invalid file names: > testConsist.R tobit2fit.R tobit2.R tobit5fit.R translogCalc.R > translogDeriv.R translogEst.R translogHessian.R translogMonoRestr.R > utils.R vcov-methods.R vcov.selection.R writeFront41in.R > Subdirectory 'man' contains invalid file names: > testConsist.Rd tobit2fit.Rd translogCalc.Rd translogDeriv.Rd > translogEst.Rd translogHessian.Rd triang.Rd vcov-methods.Rd > vcov.selection.Rd vecli2m.Rd veclipos.Rd vecli.Rd writeFront41in.Rd > * checking for LF line-endings in source and make files > * checking for empty or unneeded directories > * building 'micEcon_0.3-8.tar.gz' > > Of course, the package does not work because of removal of these files. It is > hard for me to see anything illegal in the listed file names. Even more, > everything works perfectly, if I run the command from "C" locale: > > [EMAIL PROTECTED]:~/tyyq/econ/micEcon$ LC_ALL="C" R CMD build trunk > * checking for file 'trunk/DESCRIPTION' ... OK > * preparing 'trunk': > * checking DESCRIPTION meta-information ... OK > * checking whether 'INDEX' is up-to-date ... NO > * use '--force' to overwrite the existing 'INDEX' > * removing junk files > * checking for LF line-endings in source and make files > * checking for empty or unneeded directories > * building 'micEcon_0.3-8.tar.gz' > > I can still can directly install from the subdirectory: 'R CMD INSTALL trunk' > works well regardless of locale. > > The micEcon package is available at CRAN. > > I'm not sure what to do about it, but I'm 99% sure that what is biting you is that Estonian sorts z before t, and something somewhere is using a regexp containing a-zA-Z. Presumably, R CMD build should just standardize the locale to "C" internally (it is a right pain to change all instances of a-zA-Z to [[:alpha:]], most likely not even possible to do it portably, and at any rate, packages should not come out different depending on the locale in which it was built.) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dget not restoring dput in R 2.6.0 (PR#10350)
On Wed, 17 Oct 2007, [EMAIL PROTECTED] wrote:
> Full_Name: David States
> Version: 2.6.0
> OS: Windows XP64
> Submission from: (NULL) (141.211.38.9)
>
>
> # The pair of commands
> #
> # dput(object, "file.dput")
> # object = dget("file.dput")
> #
> # should be a no op, but this is not working correctly for all objects.
Not so, and it says so on the help page:
Deparsing an object is difficult, and not always possible. With
the default 'control', 'dput()' attempts to deparse in a way that
is readable, but for more complex or unusual objects, not likely
to be parsed as identical to the original. Use 'control = "all"'
for the most complete deparsing; use 'control = NULL' for the
simplest deparsing, not even including attributes.
Had you followed the advice, your example would have worked.
dump() is more accurate than dput(), and save() more so than either.
> #
> # Simple example:
> #
> # make a simple object of class "hclust"
> cl = hclust(dist(matrix(nrow=4,ncol=4, c(1:16
> # save it to a file using dput
> dput(cl, "cl.dput")
> # the following two commands should give identical results, but they dont
> str(cl)
> str(dget("cl.dput"))
> # plot also fails to interpret the labels on the restore object correctly
> par(mfrow=c(2,1))
> plot(cl)
> plot(dget("cl.dput"))
>
> __
> 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] LazyLoad changes the class of objects
Yes, attributes are not preserved, though why that should matter
given the frequent strong recommendations in this list against
using attributes on environments or other reference objects is
beyond me. More importantly, locking and active bindings are not
preserved either. Will look into fixing this this 2.7.
luke
On Fri, 12 Oct 2007, Gabor Grothendieck wrote:
> Consider a package that this DESCRIPTION file:
>
> ---
> Package: tester
> Version: 0.1-0
> Date: 2007-10-12
> Title: Prototype object-based programming
> Author: Gabor Grothendieck
> Maintainer: Gabor Grothendieck <[EMAIL PROTECTED]>
> Description: test
> LazyLoad: true
> Depends: R (>= 2.6.0)
> License: GPL2
> ---
>
> and a single subdirectory R containing tester.R which contains two lines:
>
> ---
> e <- new.env()
> class(e) <- c("x", "environment")
> ---
>
> Now issue these commands:
>
>> library(tester)
>> class(tester::e)
> [1] "environment"
>
>> R.version.string # Windows Vista
> [1] "R version 2.6.0 Patched (2007-10-08 r43124)"
>
>
> Note that the class of e was changed from what we set it to !!!
>
> On the other handn, if we omit LazyLoad: true from the DESCRIPTION file
> then it retains its original class.
>
>> # removed LazyLoad: true line from DESCRIPTION and reinstall pkg
>> # now its ok
>> library(tester)
>> class(tester::e)
> [1] "x" "environment"
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] LazyLoad changes the class of objects
Yes (on the yes), to second Luke. Here is John Chambers' comment when
I was bitten by the same "bug" a while ago:
http://tolstoy.newcastle.edu.au/R/devel/02b/0524.html
See also Peter Dalgaard's follow up suggesting to wrap up the
environment in a list, which will typically be enough. I've been
using this "trick" successfully in the Object class (R.oo package) for
several years, where I'm putting the environment in the attributes
list of an object, i.e. obj <- NA; attr(NA, "..env") <- new.env();
It turned out at the time that this was slightly faster to access than
using a list element.
Cheers
Henrik
On 10/17/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
> Yes, attributes are not preserved, though why that should matter
> given the frequent strong recommendations in this list against
> using attributes on environments or other reference objects is
> beyond me. More importantly, locking and active bindings are not
> preserved either. Will look into fixing this this 2.7.
>
> luke
>
> On Fri, 12 Oct 2007, Gabor Grothendieck wrote:
>
> > Consider a package that this DESCRIPTION file:
> >
> > ---
> > Package: tester
> > Version: 0.1-0
> > Date: 2007-10-12
> > Title: Prototype object-based programming
> > Author: Gabor Grothendieck
> > Maintainer: Gabor Grothendieck <[EMAIL PROTECTED]>
> > Description: test
> > LazyLoad: true
> > Depends: R (>= 2.6.0)
> > License: GPL2
> > ---
> >
> > and a single subdirectory R containing tester.R which contains two lines:
> >
> > ---
> > e <- new.env()
> > class(e) <- c("x", "environment")
> > ---
> >
> > Now issue these commands:
> >
> >> library(tester)
> >> class(tester::e)
> > [1] "environment"
> >
> >> R.version.string # Windows Vista
> > [1] "R version 2.6.0 Patched (2007-10-08 r43124)"
> >
> >
> > Note that the class of e was changed from what we set it to !!!
> >
> > On the other handn, if we omit LazyLoad: true from the DESCRIPTION file
> > then it retains its original class.
> >
> >> # removed LazyLoad: true line from DESCRIPTION and reinstall pkg
> >> # now its ok
> >> library(tester)
> >> class(tester::e)
> > [1] "x" "environment"
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa Phone: 319-335-3386
> Department of Statistics andFax: 319-335-3017
> Actuarial Science
> 241 Schaeffer Hall email: [EMAIL PROTECTED]
> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
>
> __
> 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] LazyLoad changes the class of objects
On 10/17/07, Henrik Bengtsson <[EMAIL PROTECTED]> wrote: > Yes (on the yes), to second Luke. Here is John Chambers' comment when > I was bitten by the same "bug" a while ago: > > http://tolstoy.newcastle.edu.au/R/devel/02b/0524.html > > See also Peter Dalgaard's follow up suggesting to wrap up the > environment in a list, which will typically be enough. I've been > using this "trick" successfully in the Object class (R.oo package) for > several years, where I'm putting the environment in the attributes > list of an object, i.e. obj <- NA; attr(NA, "..env") <- new.env(); > It turned out at the time that this was slightly faster to access than > using a list element. This has all been discussed before but this "trick" is not sufficient for defining an environment subclass because it does not respect inheritance. The subclass writer must replicate all methods that act on environments in a subclass for an environment subclass to have them. Inheritance is completely broken. If there were N environment methods the writer of an environment subclass would have to write N methods to support them all. On the other hand, if it worked in a true OO way the subclass writer would not have to write anything. Also suppose a new environment method comes along. In true OO the subclass automatically inherits it but with the "trick" the subclass writer needs to write a new method always mimicing the parent. This is not how OO is supposed to work. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] predictable bit patterns in runif(n) shortly after set.seed
Mersenne Twister generator is known to be sensitive to the
algorithm used to generate its initial state. The initialization
used in R generates the initial state in a way, which leaves
linear dependencies mod 2 among the bits in the initial state.
Since Mersenne Twister performs only operations, which are
linear mod 2, these dependencies propagate to the output sequence.
An easy to see consequence of this may be demonstrated by
the following script:
pattern <- function(m=1400)
{
x <- runif(m)
y <- matrix(nrow=m,ncol=32)
for (j in 1:32) {
y[,j] <- floor(2*x)
x <- 2*x - y[,j]
}
u <- rep(0,times=32)
u[c(3,7,10,14,21,25,32)] <- 1
c(y %*% u) %% 2
}
RNGkind("default") # or set.seed() with any seed
z <- pattern()
abs(diff(z,lag=2)) # sequence with long constant subsequences
It should be pointed out that it is indeed a consequence of the
initialization. If e.g. runif(1) is run after RNGkind/set.seed,
then the effect disappears.
Note that each row in matrix y used in function pattern() contains
the bit representation of one of the numbers from runif(m).
Different elements of z are derived from different rows in y and,
hence, from different elements of runif(m). Consequently, they should
mimic an i.i.d. sequence. However, abs(diff(z,lag=2)) allows to
reject such an assumption easily.
The pattern is even better visible graphically, for example using
for (i in 1:20) {
set.seed(i)
z <- pattern()
z <- abs(diff(z,lag=2))
if (i == 1) {
plot(cumsum(2*z-1),type="l")
} else {
lines(cumsum(2*z-1))
}
}
The resulting curve is almost the same for all the seeds.
I have a working patch, which solves this problem by adding
a new generator called Mersenne-Twister-52, which is the
standard Mersenne Twister with the following modifications:
- It uses MRG32k5a by P.L'Ecuyer for generating the initial state
(This generator works modulo odd primes and so does not generate
dependencies of the kind to which Mersenne Twister is sensitive.)
- Combines 26 bits of two consequtive numbers into a single number
with 52 random bits (this explains its name) and adds a constant
shift 2^-53 to guarantee that the result is always in (0,1).
Combining the two changes together allows to keep the current Mersenne
Twister implementation intact for backward compatibility and provides
more reasons to add a new name than just a different seeding.
In my opinion, there may be applications, which can benefit from
more then 32 random bits in the numbers from runif(n).
I would be pleased to send the patch to R-devel, if the proposed
solution is of the sort, which could be considered.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nmle: gnls freezes on difficult case
Hi,
I am not sure this is a bug but I can repeat it, The functions and data
are below.
I know this is nasty data, and it is very questionable whether a 4pl
model
is appropriate, but it is data fed to an automated tool and I would
have hoped for an error. Does this repeat for anyone else?
My details:
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 6.0
year 2007
month 10
day03
svn rev43063
language R
version.string R version 2.6.0 (2007-10-03)
start=c(-1.5, 9.5, 0.09, 10.25)
names(start)<-c("A","B","xmid","scal")
gnls(response~SSllogis(conc,A,B,xmid,scal),tdat,start=start,weights=varPower(),verbose=TRUE)
**Iteration 1
GLS step: Objective: NULLvarStruct parameters:
power
0.3373199
NLS step: RSS = 0
model parameters:-0.799941 8.99983 -0.522623 212.314
iterations: 2
Convergence:
params varStruct
1.172208 1.00
### After about 10 min hit cntrl C
Warning messages:
1: In log(xmid) : NaNs produced
2: In log(xmid) : NaNs produced
3: In log(xmid) : NaNs produced
#
Data
tdat<-data.frame(conc=c(0.00203,0.0061,0.0183,0.0549,0.165,0.494,1.48,4.44,13.3,40),
response=c(12,-4,19,11,-5,-3,1,6,0,-8))
Self start function
SSllogis <- selfStart(~ A + (B-A)/(1 + exp(scal*(log(x)-log(xmid,
function(mCall, data, LHS)
{
#browser()
xy <- sortedXyData(mCall[["x"]], LHS, data)
if (nrow(xy) < 5) {
stop("too few distinct input values to fit a four-parameter
logistic")
}
rng <- range(xy$y)
drng <- diff(rng)
B <- rng[2] + 0.001
A <- rng[1] - 0.001
xy$prop <- log((B-xy$y)/(xy$y-A+0.001))
#(xy$y - rng[1] + 0.05 * drng)/(1.1 * drng)
ir <- as.vector(coef(lm(prop ~ log(x), data = xy)))
scal <- ir[2]
xmid <- exp(-ir[1]/ir[2])
#pars <- as.vector(coef(nls(y ~ cbind(1, 1/(1 + exp((xmid -
#x)/exp(lscal, data = xy, start = list(xmid = ir[1],
#lscal = log(abs(ir[2]))), algorithm = "plinear")))
value <- c(A, B, xmid, scal)
names(value) <- mCall[c("A", "B", "xmid", "scal")]
value
}, c("A", "B", "xmid", "scal"))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Withdrawing SaveImage
I noticed this under R 2.7.0 NEWS: o In package installation, SaveImage: yes is defunct and lazyloading is attempted instead. I think its premature to make SaveImage defunct especially when: 1. there is a bug that would be triggered in some packages by automatically using LazyLoad instead of SaveImage: https://stat.ethz.ch/pipermail/r-devel/2007-October/047118.html 2. only last year it was stated on R-devel that there was "no intention to withdraw SaveImage: yes" http://tolstoy.newcastle.edu.au/R/devel/06/02/4025.html Having "SaveImage: yes" automatically invoke LazyLoad is really tantamount to withdrawing it. At the very least making SaveImage defunct should be postponed until the bug in #1 is fixed and a period of time has elapsed during which both SaveImage and LazyLoad are available without that bug so that packages affected can gradually move over and have the ability to move back to SaveImage if the move uncovers more R bugs related to this. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
