Re: [Rd] Package compile under Windows on 2.6.0
An on-list followup after some off-list rounds of correspondence. The problem 2) was that packages defining S4 classes/methods need to be installed to use lazy loading (or SaveImage, but that is deprecated, and removed in R-devel). This package had not specified lazy loading, and the automated guesser was choosing lazyloading on Linux and not on Windows. On Tue, 9 Oct 2007, Iago Mosqueira wrote: > Dear all, > > We are experiencing some trouble when compiling R packages using R > 2.6.0 and the new Rtools installer under Windows XP. > > (1) First, compiling any package using the new setup stops with an > errorrelated to some "/" issue on the inst folder. This folder only > contains a CITATION file > > -- Making package FLCore > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > making DLL ... > making FLCoreClasses.d from FLCoreClasses.cpp > g++-sjlj -Ic:/progra~1/r/r-2.6.0/include-Wall -O2 -c > FLCoreClasses.cpp -o FLCoreClasses.o > windres --preprocessor="gcc-sjlj -E -xc -DRC_INVOKED" -I > c:/progra~1/r/r-2.6.0/include -i FLCore_res.rc -o FLCore_res.o > g++-sjlj -shared -s -o FLCore.dll FLCore.def FLCoreClasses.o > FLCore_res.o -Lc:/progra~1/r/r-2.6.0/bin-lR > ... DLL made > installing DLL > installing R files > installing inst files > rm: failed to get attributes of `/': No such file or directory > rm: failed to get attributes of `/': No such file or directory > installing data files > rm: failed to get attributes of `/': No such file or directory > make[2]: *** [C:/Sandbox/R260built/FLCore.Rcheck/FLCore/data] Error 1 > make[1]: *** [all] Error 2 > make: *** [pkg-FLCore] Error 2 > *** Installation of FLCore failed *** > > (2) Testing with the previous Rtoolset with updated MinGW and Perl, a > package from CRAN can be compiled (VR), but our package now fails with > > -- Making package FLCore > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > installing R files > installing inst files > installing data files > installing man source files > installing indices > Error in eval(expr, envir, enclos) : could not find function "setClass" > Error: unable to load R code in package 'FLCore' > Execution halted > make[2]: *** [indices] Error 1 > make[1]: *** [all] Error 2 > make: *** [pkg-FLCore] Error 2 > *** Installation of FLCore failed *** > > methods is loaded trhough a require(methods) inside an .onLoad call. > > (3) The package compiles on a Linux machine with R 2.6.0 > > Is there any issue with MinGW or the Rtools he should consider? > > Many thanks, > > > Iago > > __ > 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
[Rd] Bug repository temporarily stalled
As part of a system upgrade just before Oct 1, the Dept. of Public Health no longer uses sendmail for incoming mail. This, unfortunately, also killed all user-level procmail filtering and hence also the r-bugs mail interface, so reports are being received but not processed. Now that they have realized it, the IT guys are working on a fix, so please have a little patience -- 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
[Rd] corMatrix crashes with corARMA structure (PR#9952)
Full_Name: Benjamin Tyner Version: 2.6.0 RC 2007-10-01 r43043 OS: WinXP Submission from: (NULL) (171.161.224.10) platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status RC major 2 minor 6.0 year 2007 month 10 day01 svn rev43043 language R version.string R version 2.6.0 RC (2007-10-01 r43043) I have seen this in other versions/platforms as well. Brian Ripley informs me the segfault is in corStruct.c Code to reproduce: n <- 100 # example from Box and Jenkins p. 83 arcoefs <- c(0.8) macoefs <- c(-0.6) p <- length(arcoefs) q <- length(macoefs) require(nlme) tmp <- corARMA(value=c(arcoefs,macoefs), form=~1, p=p, q=q) Sigma <- corMatrix(tmp, covariate = 1:n) # segfault __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pt inaccurate when x is close to 0 (PR#9945)
Full_Name: Skylab Gupta Version: R version 2.5.1 (2007-06-27) OS: Windows XP Submission from: (NULL) (216.82.144.137) Hello, I have been playing around with the statistical distributions in R. I think the computations for the cumulative distribution function of the students t distribution in R are not very accurate. For instance, the cdf of a students t distribution with 13 degrees of freedom at 1e-4 is reported in R as "0.5000391350986764"; from Mathematica, it seems the correct value is "0.50003913510150055", only about 9 accurate digits reported in R. I also did the following from within R: - df<-seq(1,100,by=1) y<-pt(1e-4,df) z<-c(0.50003183098839799,0.50003535533895194,0.50003675525997071,0.5000374985481,0.50003796066840744,0.50003827327749706,0.50003849914427922,0.50003866990364754,0.50003880349244212,0.50003891083995444,0.50003899897813187,0.50003907263208447,0.50003913510150055,0.50003918874627440,0.50003923531785055,0.50003927612461441,0.50003931217478748,0.50003934425324170,0.50003937297989520,0.50003939886014204,0.50003942229165621,0.50003944360703978,0.50003946308016112,0.50003948094039441,0.50003949738053710,0.50003951256485324,0.50003952663295181,0.50003953969680248,0.50003955185925653,0.50003956322006460,0.50003957385523301,0.50003958382054481,0.50003959318443636,0.50003960200394315,0.50003961032679112,0.50003961818144815,0.50003962562026172,0.50003963266089213,0.50003963934773465,0.50003964569404735,0.50003965173577758,0.50003965749688895,0.50003966298323521,0.50003966823056478,0.50003967322766096,0.50003967801868676,0.50003968260005904,0.50003968700228751,0.50003969121916547,0.500 03969526955183,0.50003969915340063,0.50003970290428668,0.50003970650705731,0.50003970997149927,0.50003971332909936,0.50003971654204993,0.50003971964040972,0.50003972264367180,0.50003972553808163,0.50003972835715427,0.50003973106835642,0.50003973370765664,0.50003973624942966,0.50003973868896101,0.50003974107556448,0.50003974338818691,0.50003974563557085,0.50003974781567961,0.50003974993203681,0.50003975199594708,0.50003975399737965,0.50003975593675354,0.50003975782715593,0.50003975966389691,0.50003976145762119,0.50003976321975063,0.50003976489560775,0.50003976655049909,0.50003976818673812,0.50003976975798736,0.50003977127434285,0.50003977277055756,0.50003977423495483,0.50003977566285773,0.50003977705769798,0.50003977841313474,0.50003977975147973,0.50003978102874791,0.50003978230822732,0.50003978356836509,0.50003978477872879,0.50003978596096421,0.50003978713049724,0.50003978827577344,0.50003978935715154,0.50003979045422919,0.50003979153680134,0.50003979256756137,0.500039793589 57851,0.50003979462027492) plot(df,(y-z)/z, type="s") - In the above R code, df contains the 100 integers between 1-100, y contains the cdf of the students t distribution computed at 1e-4 from R, for all the df degrees of freedom; and z contains the correct values (to 17 decimal digits) of the students t distribution cdf at 1e-4 computed from Mathematica; when I plot the relative errors between the computed values from Mathematica and R, it seems the relative errors are large; we get only about 10-12 digits of accuracy from R rather than about 15 digits (all this assuming that the Mathematica computed values are correct). This happens for all values close to 0 where the cdf is evaluated. I am working on Windows XP, and I installed a precompiled binary version of R. The following information might also be useful: --- > sessionInfo() R version 2.5.1 (2007-06-27) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] "stats" "graphics" "grDevices" "utils" "datasets" "methods" "base" > version platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 5.1 year 2007 month 06 day27 svn rev42083 language R version.string R version 2.5.1 (2007-06-27) --- Is there a reason for this loss of accuracy, or am I missing something here? Thanks. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] documentation of .C (PR#9948)
Full_Name: Martin Schlather
Version: R version 2.7.0 Under development (unstable) (2007-10-01 r43043)
OS: Linux
Submission from: (NULL) (91.3.209.203)
Hi,
There are 2 dangers with using 'DUP=FALSE' mentioned:
* formal arguments
* lists
Would you also mention a third one, namely
that values in R are now only referenced whenever
possible and not always copied; hence .C(..., DUP=FALSE)
may change the values of other local variables.
E.g., with C code
void addone(double *x) { *x = *x + 1; }
you get
x <- as.double(1)
y <- x
.C("addone", x, PACKAGE="test", DUP=FALSE)
print(c(x,y))
#[1] 2 2
x <- as.double(1)
y <- as.double(x)
.C("addone", x, PACKAGE="test", DUP=FALSE)
print(c(x,y))
#[1] 2 2
x <- as.double(1)
y <- as.integer(x)
.C("addone", x, PACKAGE="test", DUP=FALSE)
print(c(x,y))
#[1] 2 1
Many thanks and kind regards,
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] gregexpr (PR#9965)
Full_Name: Peter Dolan
Version: 2.5.1
OS: Windows
Submission from: (NULL) (128.193.227.43)
gregexpr does not find all matching substrings if the substrings overlap:
> gregexpr("abab","ababab")
[[1]]
[1] 1
attr(,"match.length")
[1] 4
It does work correctly in Version 2.3.1 under linux.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rendering dashed steps produces solid horizontal lines (PR#9953)
Full_Name: Chris Bainbridge
Version: 2.2.1
OS: Linux
Submission from: (NULL) (86.157.4.96)
The following python script will render two pdf files, one with lines and one
with steps. The pdf with steps (s.pdf) renders the horizontal line as a solid
when it should be dotted as in lpdf. It seems as though R tries to render every
data point individually when using steps, but manages to join them all together
as a straight line when using lines.
#!/usr/bin/python
import os
f=open('x.txt','w')
i=0
f.write('x y\n')
while i<100:
f.write('%f %f\n'%(i,0.5))
i+=1
f.close()
rscr="""pdf('%s.pdf')
d <- read.table('x.txt', header=T)
attach(d)
plot(x,y, bty='n', las=1, lty=2,type='%s')
"""
f=open('l.r','w')
f.write(rscr%('l','l'))
f.close()
os.system('R -q --no-save < l.r')
f=open('s.r','w')
f.write(rscr%('s','s'))
f.close()
os.system('R -q --no-save < s.r')
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-2.6.0> problem to load library(stats) (PR#9956)
Hello, I just installed R-2.6.0 on my computer (OSX 10.4.10, ppc) and get the following message when I try to load the library stats: > library(stats) Error in dyn.load(file, ...) : kann shared library '/Library/Frameworks/R.framework/Resources/ library/stats/libs/ppc/stats.so' nicht laden: dlopen(/Library/Frameworks/R.framework/Resources/library/stats/libs/ ppc/stats.so, 6): Library not loaded: /usr/local/lib/libgfortran.2.dylib Referenced from: /Library/Frameworks/R.framework/Resources/library/ stats/libs/ppc/stats.so Reason: image not found Fehler: Laden von Paket/Namensraum f"ur 'stats' fehlgeschlagen This warning also appears at the startup of R. Kind Regards, DlC __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package Geneland / Rgui under windows (PR#9964)
Full_Name: Gilles Guillot Version: 2.6.0 OS: windows XP professional Submission from: (NULL) (129.240.88.50) This sequence of command does not work in the R gui 2.6.0: library(Geneland) set.seed(1) data <- simdata(nindiv=200, coord.lim=c(0,1,0,1) , number.nuclei=5 , allele.numbers=rep(10,20), IBD=FALSE, npop=2, give.tess.grid=FALSE) geno <- data$genotypes coord <- t(data$coord.indiv) path.mcmc <- paste(tempdir(),"/",sep="") set.seed(1) mcmcFmodel(coordinates=coord, genotypes=geno, path.mcmc=path.mcmc, rate.max=10, delta.coord=0, npopmin=1, npopinit=5, npopmax=5, nb.nuclei.max=50, nit=500, thinning=1, freq.model="Dirichlet", varnpop=FALSE, spatial=TRUE) the call to mcmcFmodel freezes R The same sequence of command works in the R command line of R 2.6.0 and also in the R GUI of 2.5.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] corMatrix crashes with corARMA structure (PR#9982)
Full_Name: Benjamin Tyner Version: 2.6.0 RC 2007-10-01 r43043 OS: WinXP Submission from: (NULL) (171.161.224.10) platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status RC major 2 minor 6.0 year 2007 month 10 day01 svn rev43043 language R version.string R version 2.6.0 RC (2007-10-01 r43043) I have seen this in other versions/platforms as well. Brian Ripley informs me the segfault is in corStruct.c Code to reproduce: n <- 100 # example from Box and Jenkins p. 83 arcoefs <- c(0.8) macoefs <- c(-0.6) p <- length(arcoefs) q <- length(macoefs) require(nlme) tmp <- corARMA(value=c(arcoefs,macoefs), form=~1, p=p, q=q) Sigma <- corMatrix(tmp, covariate = 1:n) # segfault __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gregexpr (PR#9965)
If you want all the matches (including overlaps) then you could try one
of these:
> gregexpr("(?=abab)","ababab",perl=TRUE)
[[1]]
[1] 1 3
attr(,"match.length")
[1] 0 0
> gregexpr("ab(?=ab)","ababab",perl=TRUE)
[[1]]
[1] 1 3
attr(,"match.length")
[1] 2 2
The book "Mastering Regular Expressions" by Jeffrey Friedl has a lot of
detail on the hows and whys of regular expression matching.
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Wednesday, October 10, 2007 8:36 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [Rd] gregexpr (PR#9965)
>
> Full_Name: Peter Dolan
> Version: 2.5.1
> OS: Windows
> Submission from: (NULL) (128.193.227.43)
>
>
> gregexpr does not find all matching substrings if the
> substrings overlap:
>
> > gregexpr("abab","ababab")
> [[1]]
> [1] 1
> attr(,"match.length")
> [1] 4
>
> It does work correctly in Version 2.3.1 under linux.
>
> __
> 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] corMatrix crashes with corARMA structure (PR#9952)
This is what I get on R 2.6.0, Win XP ciao Simone P.S. you have posted twice > n <- 100 > > # example from Box and Jenkins p. 83 > arcoefs <- c(0.8) > macoefs <- c(-0.6) > p <- length(arcoefs) > q <- length(macoefs) > > require(nlme) > tmp <- corARMA(value=c(arcoefs,macoefs), form=~1, p=p, q=q) > Sigma <- corMatrix(tmp, covariate = 1:n) # segfault Error in corMatrix.corARMA(tmp, covariate = 1:n) : 'object' has not been Initialize()d > noquote(unlist(R.Version())) platform arch os system i386-pc-mingw32 i386 mingw32i386, mingw32 status majorminor year 2 6.0 2007 month day svn rev language 10 0343063R version.string R version 2.6.0 (2007-10-03) > On 10/10/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Full_Name: Benjamin Tyner > Version: 2.6.0 RC 2007-10-01 r43043 > OS: WinXP > Submission from: (NULL) (171.161.224.10) > > > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status RC > major 2 > minor 6.0 > year 2007 > month 10 > day01 > svn rev43043 > language R > version.string R version 2.6.0 RC (2007-10-01 r43043) > > I have seen this in other versions/platforms as well. Brian Ripley informs > me > the segfault is in corStruct.c > > Code to reproduce: > > n <- 100 > > # example from Box and Jenkins p. 83 > arcoefs <- c(0.8) > macoefs <- c(-0.6) > p <- length(arcoefs) > q <- length(macoefs) > > require(nlme) > tmp <- corARMA(value=c(arcoefs,macoefs), form=~1, p=p, q=q) > Sigma <- corMatrix(tmp, covariate = 1:n) # segfault > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax: +39 051 232153 http://www2.stat.unibo.it/giannerini/ __ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pt inaccurate when x is close to 0 (PR#9945)
On 10/10/2007 10:35 AM, [EMAIL PROTECTED] wrote: > Full_Name: Skylab Gupta > Version: R version 2.5.1 (2007-06-27) > OS: Windows XP > Submission from: (NULL) (216.82.144.137) > > > Hello, > > I have been playing around with the statistical distributions in R. I think > the > computations for the cumulative distribution function of the students t > distribution in R are not very accurate. > > For instance, the cdf of a students t distribution with 13 degrees of freedom > at > 1e-4 is reported in R as "0.5000391350986764"; from Mathematica, it seems the > correct value is "0.50003913510150055", only about 9 accurate digits reported > in > R. As Charles Berry told you when this was posted to R-help, it looks as though it is Mathematica that is inaccurate. For example, I would expect this plot to be smooth, and it is not in either R or Mathematica, but R is at least monotone: # the Mathematica values plot(diff(z[80:100]), type='l') The R values plot(diff(pt(1e-4, df=80:100)), type='l') > > I also did the following from within R: > > - > df<-seq(1,100,by=1) > y<-pt(1e-4,df) > z<-c(0.50003183098839799,0.50003535533895194,0.50003675525997071,0.5000374985481,0.50003796066840744,0.50003827327749706,0.50003849914427922,0.50003866990364754,0.50003880349244212,0.50003891083995444,0.50003899897813187,0.50003907263208447,0.50003913510150055,0.50003918874627440,0.50003923531785055,0.50003927612461441,0.50003931217478748,0.50003934425324170,0.50003937297989520,0.50003939886014204,0.50003942229165621,0.50003944360703978,0.50003946308016112,0.50003948094039441,0.50003949738053710,0.50003951256485324,0.50003952663295181,0.50003953969680248,0.50003955185925653,0.50003956322006460,0.50003957385523301,0.50003958382054481,0.50003959318443636,0.50003960200394315,0.50003961032679112,0.50003961818144815,0.50003962562026172,0.50003963266089213,0.50003963934773465,0.50003964569404735,0.50003965173577758,0.50003965749688895,0.50003966298323521,0.50003966823056478,0.50003967322766096,0.50003967801868676,0.50003968260005904,0.50003968700228751,0.50003969121916547,0. 500 > > 03969526955183,0.50003969915340063,0.50003970290428668,0.50003970650705731,0.50003970997149927,0.50003971332909936,0.50003971654204993,0.50003971964040972,0.50003972264367180,0.50003972553808163,0.50003972835715427,0.50003973106835642,0.50003973370765664,0.50003973624942966,0.50003973868896101,0.50003974107556448,0.50003974338818691,0.50003974563557085,0.50003974781567961,0.50003974993203681,0.50003975199594708,0.50003975399737965,0.50003975593675354,0.50003975782715593,0.50003975966389691,0.50003976145762119,0.50003976321975063,0.50003976489560775,0.50003976655049909,0.50003976818673812,0.50003976975798736,0.50003977127434285,0.50003977277055756,0.50003977423495483,0.50003977566285773,0.50003977705769798,0.50003977841313474,0.50003977975147973,0.50003978102874791,0.50003978230822732,0.50003978356836509,0.50003978477872879,0.50003978596096421,0.50003978713049724,0.50003978827577344,0.50003978935715154,0.50003979045422919,0.50003979153680134,0.50003979256756137,0.500039793 589 > 57851,0.50003979462027492) > > plot(df,(y-z)/z, type="s") > - > > In the above R code, df contains the 100 integers between 1-100, y contains > the > cdf of the students t distribution computed at 1e-4 from R, for all the df > degrees of freedom; and z contains the correct values (to 17 decimal digits) > of > the students t distribution cdf at 1e-4 computed from Mathematica; when I plot > the relative errors between the computed values from Mathematica and R, it > seems > the relative errors are large; we get only about 10-12 digits of accuracy > from R > rather than about 15 digits (all this assuming that the Mathematica computed > values are correct). It seems you are making a bad assumption. Duncan Murdoch This happens for all values close to 0 where the cdf is > evaluated. > > I am working on Windows XP, and I installed a precompiled binary version of R. > The following information might also be useful: > > --- >> sessionInfo() > R version 2.5.1 (2007-06-27) > i386-pc-mingw32 > > locale: > LC_COLLATE=English_United States.1252;LC_CTYPE=English_United > States.1252;LC_MONETARY=English_United > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 > > attached base packages: > [1] "stats" "graphics" "grDevices" "utils" "datasets" "methods" > "base" > >> version > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major 2 > minor 5.1 > year 2007 > month 06 > day27 > svn rev42083 > language R
Re: [Rd] pt inaccurate when x is close to 0 (PR#9945)
On Wed, 10 Oct 2007, Duncan Murdoch wrote: > On 10/10/2007 10:35 AM, [EMAIL PROTECTED] wrote: >> Full_Name: Skylab Gupta >> Version: R version 2.5.1 (2007-06-27) >> OS: Windows XP >> Submission from: (NULL) (216.82.144.137) >> >> >> Hello, >> >> I have been playing around with the statistical distributions in R. I think >> the >> computations for the cumulative distribution function of the students t >> distribution in R are not very accurate. >> >> For instance, the cdf of a students t distribution with 13 degrees of >> freedom at >> 1e-4 is reported in R as "0.5000391350986764"; from Mathematica, it seems the >> correct value is "0.50003913510150055", only about 9 accurate digits >> reported in >> R. > > As Charles Berry told you when this was posted to R-help, it looks as > though it is Mathematica that is inaccurate. For example, I would > expect this plot to be smooth, and it is not in either R or Mathematica, > but R is at least monotone: > > # the Mathematica values > plot(diff(z[80:100]), type='l') > > The R values > plot(diff(pt(1e-4, df=80:100)), type='l') > Further, if one truly needs to get highly accurate values for pt( near.zero, df ) recognize that dt(x, df ) is nearly quadratic around x==0 and dominated by a linear component for x > 0. So, simple quadrature gets the area under the density for (0, near.zero] quite accurately. One knows that pt(0, df) is exactly 0.5, so this can be added to get the result. This one point quadrature rule is accurate to better than 3e-14 for every df %in% 1:100 : really.simple.values <- 0.5 + sapply( 1:100, function(y) dt( 0.5e-04, y ) * 1e-04 ) Three point Gaussian quadrature (is overkill and) seems accurate up to machine precision. Chuck >> >> I also did the following from within R: >> >> - >> df<-seq(1,100,by=1) >> y<-pt(1e-4,df) >> z<-c(0.50003183098839799,0.50003535533895194,0.50003675525997071,0.5000374985481,0.50003796066840744,0.50003827327749706,0.50003849914427922,0.50003866990364754,0.50003880349244212,0.50003891083995444,0.50003899897813187,0.50003907263208447,0.50003913510150055,0.50003918874627440,0.50003923531785055,0.50003927612461441,0.50003931217478748,0.50003934425324170,0.50003937297989520,0.50003939886014204,0.50003942229165621,0.50003944360703978,0.50003946308016112,0.50003948094039441,0.50003949738053710,0.50003951256485324,0.50003952663295181,0.50003953969680248,0.50003955185925653,0.50003956322006460,0.50003957385523301,0.50003958382054481,0.50003959318443636,0.50003960200394315,0.50003961032679112,0.50003961818144815,0.50003962562026172,0.50003963266089213,0.50003963934773465,0.50003964569404735,0.50003965173577758,0.50003965749688895,0.50003966298323521,0.50003966823056478,0.50003967322766096,0.50003967801868676,0.50003968260005904,0.50003968700228751,0.50003969121916547,0. > 500 >> >> 03969526955183,0.50003969915340063,0.50003970290428668,0.50003970650705731,0.50003970997149927,0.50003971332909936,0.50003971654204993,0.50003971964040972,0.50003972264367180,0.50003972553808163,0.50003972835715427,0.50003973106835642,0.50003973370765664,0.50003973624942966,0.50003973868896101,0.50003974107556448,0.50003974338818691,0.50003974563557085,0.50003974781567961,0.50003974993203681,0.50003975199594708,0.50003975399737965,0.50003975593675354,0.50003975782715593,0.50003975966389691,0.50003976145762119,0.50003976321975063,0.50003976489560775,0.50003976655049909,0.50003976818673812,0.50003976975798736,0.50003977127434285,0.50003977277055756,0.50003977423495483,0.50003977566285773,0.50003977705769798,0.50003977841313474,0.50003977975147973,0.50003978102874791,0.50003978230822732,0.50003978356836509,0.50003978477872879,0.50003978596096421,0.50003978713049724,0.50003978827577344,0.50003978935715154,0.50003979045422919,0.50003979153680134,0.50003979256756137,0.500039793 > 589 >> 57851,0.50003979462027492) >> >> plot(df,(y-z)/z, type="s") >> - >> >> In the above R code, df contains the 100 integers between 1-100, y contains >> the >> cdf of the students t distribution computed at 1e-4 from R, for all the df >> degrees of freedom; and z contains the correct values (to 17 decimal digits) >> of >> the students t distribution cdf at 1e-4 computed from Mathematica; when I >> plot >> the relative errors between the computed values from Mathematica and R, it >> seems >> the relative errors are large; we get only about 10-12 digits of accuracy >> from R >> rather than about 15 digits (all this assuming that the Mathematica computed >> values are correct). > > It seems you are making a bad assumption. > > Duncan Murdoch > > > > This happens for all values close to 0 where the cdf is >> evaluated. >> >> I am working on Windows XP, and I installed a precompiled binary version of >> R. >> The following information might also be useful: >> >> --- >>> sessionInfo() >> R version 2.5.1 (2007-06-27) >> i386-pc-mingw32 >> >> locale: >> LC_COLLATE=English_United States.1252;LC_CTYPE=Engl
Re: [Rd] documentation of .C (PR#9948)
On Wed, 10 Oct 2007, [EMAIL PROTECTED] wrote: > Full_Name: Martin Schlather > Version: R version 2.7.0 Under development (unstable) (2007-10-01 r43043) > OS: Linux > Submission from: (NULL) (91.3.209.203) > > > Hi, > > There are 2 dangers with using 'DUP=FALSE' mentioned: > * formal arguments > * lists > > Would you also mention a third one, namely > that values in R are now only referenced whenever > possible and not always copied; hence .C(..., DUP=FALSE) > may change the values of other local variables. > How about a warning like "if you pass a local variable to .C/.Fortran with DUP=FALSE, your compiled code can alter the local variable and not just the copy in the return list. " -thomas (copied from ?.C, of course) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.6.0> problem to load library(stats) (PR#9956)
Dominique, please make sure you have the correct, current R binary from CRAN. It should have the MD5 hash of ff218b4e5687077c0078ca4948be1205 (for the full R). If it doesn't, please make sure you fetch it from another mirror. For a very brief period of time (less than 24h) there was a binary featuring the problem you list, but it was fixed immediately. Cheers, Simon On Oct 10, 2007, at 10:35 AM, [EMAIL PROTECTED] wrote: > Hello, > > I just installed R-2.6.0 on my computer (OSX 10.4.10, ppc) and get > the following message when I try to load the library stats: > >> library(stats) > Error in dyn.load(file, ...) : >kann shared library '/Library/Frameworks/R.framework/Resources/ > library/stats/libs/ppc/stats.so' nicht laden: > dlopen(/Library/Frameworks/R.framework/Resources/library/stats/libs/ > ppc/stats.so, 6): Library not loaded: /usr/local/lib/libgfortran. > 2.dylib >Referenced from: /Library/Frameworks/R.framework/Resources/library/ > stats/libs/ppc/stats.so >Reason: image not found > Fehler: Laden von Paket/Namensraum f"ur 'stats' fehlgeschlagen > > > This warning also appears at the startup of R. > > > Kind Regards, > DlC > > __ > 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] documentation of .C (PR#9948)
On Wed, 10 Oct 2007, [EMAIL PROTECTED] wrote:
> Full_Name: Martin Schlather
> Version: R version 2.7.0 Under development (unstable) (2007-10-01 r43043)
> OS: Linux
> Submission from: (NULL) (91.3.209.203)
>
>
> Hi,
>
> There are 2 dangers with using 'DUP=FALSE' mentioned:
> * formal arguments
> * lists
>
> Would you also mention a third one, namely
> that values in R are now only referenced whenever
> possible and not always copied; hence .C(..., DUP=FALSE)
> may change the values of other local variables.
That has always been the case (depending on the meaning of 'possible'),
and is part of the first point made. It *does* give a circumstance in
which other variables can be changed. Spelling out all of those (and
'local' is not really relevant) would be a mammoth task.
> E.g., with C code
> void addone(double *x) { *x = *x + 1; }
>
> you get
>
> x <- as.double(1)
> y <- x
> .C("addone", x, PACKAGE="test", DUP=FALSE)
> print(c(x,y))
> #[1] 2 2
>
>
> x <- as.double(1)
> y <- as.double(x)
> .C("addone", x, PACKAGE="test", DUP=FALSE)
> print(c(x,y))
> #[1] 2 2
>
> x <- as.double(1)
> y <- as.integer(x)
> .C("addone", x, PACKAGE="test", DUP=FALSE)
> print(c(x,y))
> #[1] 2 1
These are the result of changing an actual argument.
--
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
[Rd] slow load() in R2.6.0
I'm encountering excruciatingly slow load times for character vectors in R 2.6.0-- up to 30sec for a 15K file that contains a no-attributes character vector of length ~1e4 and object size ~0.5MB. In R 2.5.1, repeated loads of the same set of files are near-instantaneous. The problem is proving tricky to reproduce consistently from scratch, so I have attached the 3 files used in the examples below. If I create a similar-looking object from scratch, then save it and re-load it a few times, the problem doesn't always occur... at least not in that session. FWIW I have noticed that the time taken to load seems to be roughly a power of 2 of the "base slow load time"-- could be a red herring. The problem seems specific to character vectors-- I noticed it with entire workspaces and have whittled it down to char vecs only. The example below is from a brand-new session with only the basic packages loaded; delays in my real sessions are much longer. Mark Bravington CSIRO Mathematical & Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > system.time( load( 'd:/r2.0/t1.rda')) user system elapsed 0.5 0.0 0.5 > system.time( load( 'd:/r2.0/t1.rda')) # same file; slower user system elapsed 3.5 0.0 3.5 > system.time( load( 'd:/r2.0/t1.rda')) user system elapsed 4.130.004.13 > system.time( load( 'd:/r2.0/t1.rda')) user system elapsed 3.510.003.52 > system.time( load( 'd:/r2.0/t2.rda')) # different bigger file user system elapsed 4.420.004.42 > system.time( load( 'd:/r2.0/t2.rda')) # same file; slower user system elapsed 10.440.00 10.44 > system.time( load( 'd:/r2.0/t2.rda')) user system elapsed 10.790.00 10.80 > system.time( load( 'd:/r2.0/t2.rda')) user system elapsed 10.390.00 10.41 > system.time( load( 'd:/r2.0/t1.rda')) # the smaller file again; slower user system elapsed 10.670.00 10.69 > system.time( load( 'd:/r2.0/t3.rda')) # different smaller file user system elapsed 10.510.00 10.52 > system.time( load( 'd:/r2.0/t2.rda')) # now bigger file again: slower user system elapsed 14.610.00 14.61 --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 2 minor = 6.0 year = 2007 month = 10 day = 03 svn rev = 43063 language = R version.string = R version 2.6.0 (2007-10-03) Windows XP (build 2600) Service Pack 2.0 Locale: LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 Search Path: Search Path: .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slow load() in R2.6.0
On Thu, 11 Oct 2007, [EMAIL PROTECTED] wrote: > I'm encountering excruciatingly slow load times for character vectors in > R 2.6.0-- up to 30sec for a 15K file that contains a no-attributes > character vector of length ~1e4 and object size ~0.5MB. In R 2.5.1, > repeated loads of the same set of files are near-instantaneous. > > The problem is proving tricky to reproduce consistently from scratch, so > I have attached the 3 files used in the examples below. There was no attachment: since these are (I presume) binary files, can you not put them on a website (as suggested by the posting guide)? > If I create a similar-looking object from scratch, then save it and > re-load it a few times, the problem doesn't always occur... at least not > in that session. > > > FWIW I have noticed that the time taken to load seems to be roughly a > power of 2 of the "base slow load time"-- could be a red herring. > > The problem seems specific to character vectors-- I noticed it with > entire workspaces and have whittled it down to char vecs only. > > The example below is from a brand-new session with only the basic > packages loaded; delays in my real sessions are much longer. Can you please try R-patched or R-devel. We've found and solved a couple of performance issues with creating STRSXPs, but with character vectors of the millions of elements. I tried several examples of around 1 elements and got times of at most 0.05 secs in 2.6.0. These included parts of those examples on which we had seen performance issues. A few clues: - even your base time is much slower than I would expect. - you say 'a 15K file ... object size ~0.5MB'. That's pretty phenomenal compression, and I am seeing file sizes more like 100Kb for objects that size. Since object.size does take into account duplication, one way to get that would be to have all unique elements. At ca 50bytes per element you would need an average string length of about 15 chars. Such an object takes about 200Kb as a .rda file. > > > Mark Bravington > CSIRO Mathematical & Information Sciences > Marine Laboratory > Castray Esplanade > Hobart 7001 > TAS > > ph (+61) 3 6232 5118 > fax (+61) 3 6232 5012 > mob (+61) 438 315 623 > > > > Type 'demo()' for some demos, 'help()' for on-line help, or > 'help.start()' for an HTML browser interface to help. > Type 'q()' to quit R. > >> system.time( load( 'd:/r2.0/t1.rda')) > user system elapsed >0.5 0.0 0.5 >> system.time( load( 'd:/r2.0/t1.rda')) # same file; slower > user system elapsed >3.5 0.0 3.5 >> system.time( load( 'd:/r2.0/t1.rda')) > user system elapsed > 4.130.004.13 >> system.time( load( 'd:/r2.0/t1.rda')) > user system elapsed > 3.510.003.52 > >> system.time( load( 'd:/r2.0/t2.rda')) # different bigger file > user system elapsed > 4.420.004.42 >> system.time( load( 'd:/r2.0/t2.rda')) # same file; slower > user system elapsed > 10.440.00 10.44 >> system.time( load( 'd:/r2.0/t2.rda')) > user system elapsed > 10.790.00 10.80 >> system.time( load( 'd:/r2.0/t2.rda')) > user system elapsed > 10.390.00 10.41 >> system.time( load( 'd:/r2.0/t1.rda')) # the smaller file again; slower > user system elapsed > 10.670.00 10.69 >> system.time( load( 'd:/r2.0/t3.rda')) # different smaller file > user system elapsed > 10.510.00 10.52 >> system.time( load( 'd:/r2.0/t2.rda')) # now bigger file again: slower > user system elapsed > 14.610.00 14.61 > > > > --please do not edit the information below-- > > Version: > platform = i386-pc-mingw32 > arch = i386 > os = mingw32 > system = i386, mingw32 > status = > major = 2 > minor = 6.0 > year = 2007 > month = 10 > day = 03 > svn rev = 43063 > language = R > version.string = R version 2.6.0 (2007-10-03) > > Windows XP (build 2600) Service Pack 2.0 > > Locale: > LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON > ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 > > Search Path: > Search Path: > .GlobalEnv, package:stats, package:graphics, package:grDevices, > package:utils, package:datasets, package:methods, Autoloads, > package:base > -- 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
