Re: [Rd] compiling R-devel *on Windows*
This is pretty clearly a problem in texi2dvi (which is part of MiKTeX), not in R, since the line passed is texi2dvi --pdf --texinfo="@set UseExternalXrefs " R-FAQ.texi I get This is pdfTeX, Version 3.141592-1.40.4 (MiKTeX 2.6) entering extended mode (c:\DOCUME~1\ripley\LOCALS~1\Temp\mik54358\_xtr\R-FAQ.texi (C:\packages\miktex2.6\tex\texinfo\base\texinfo.tex ... I think your TMP variable is set to a Cygwin-style path, although when I experimented with that MiKTeX dropped back to c:\TEMP. On Fri, 31 Aug 2007, Duncan Murdoch wrote: > [EMAIL PROTECTED] wrote: >> Hello. >> >> I am in a habit of compiling daily snapshots of R-devel and R-patched on my >> Windows XP workstation. I have cygwin environment with up-to-date RTools >> and MiKTeX. I run cygwin and MiKTeX upadaters pretty often (every couple >> of days) so both of them are reasonably current. >> >> Recently I noticed a small annoyance when compiling R-dvel. It started >> happening right after I updated to the new version of RTools (containing >> MinGW 4.2.1-sjlj compilers). Everything else stayed the same with possible >> exception of MiKTeX update. But there was a change to use texi2dvi if present a couple of weeks ago. >> I usually just type "make distribution" to compile everything. The >> compilation itself goes smoothly. Then the PDF version of the reference >> manual is created. Then I see this: >> >> ... >> Output written on refman.pdf (1563 pages, 7869936 bytes). >> Transcript written on refman.log. >> creating doc/manual/version.texi >> texi2dvi --pdf --texinfo="@set UseExternalXrefs " R-FAQ.texi >> This is pdfTeX, Version 3.141592-1.40.4 (MiKTeX 2.6) >> entering extended mode >> ! I can't find file `\tmp\t2d6036\xtr\R-FAQ.texi'. >> <*> /tmp/t2d6036/xtr/R-FAQ.texi >> >> Please type another input file name: >> >> Now the file /tmp/t2d6036/xtr/R-FAQ.texi exists at this point is not empty >> and has usual protection codes. I tried different versions of back and >> front slashes, double backslashes, etc., but to no avail. I was getting >> the same message - the file cannot be found. The only thing that works is >> the plain file name. That is, if I just type (or copy and paste) the >> string R-FAQ.texi everything works fine. This happens three times for >> every manual (except the refman). After that the compilation ends >> normally, the windows installer is created and, when I run the installer, I >> get everything working correctly including PDFs of the manuals. >> >> It looks to me like the /tmp/t2d6036/xtr/ part of the name gets already >> pre-pended to whatever name the make process provides so it expects just >> the file name. Alternatively, something changed in my MiKTeX setup due to >> updates. However, the refman compiles properly and I can also compile >> other LaTeX with no apparent problems. >> >> Thanks in advance, > > How do you have your temp directory set? I'm not sure if it's R or one > of the build tools that's important here, so it's worth looking at all > environment variables TMPDIR, TEMP, TMP, etc. > > Are you running the build in Cygwin, or in a Windows CMD window? I use > Cygwin (not quite so current as yours) and don't see this error. > > Duncan Murdoch > > __ > 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] Friday question: negative zero
On 8/31/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > The IEEE floating point standard allows for negative zero, but it's hard > to know that you have one in R. One reliable test is to take the > reciprocal. For example, > > > y <- 0 > > 1/y > [1] Inf > > y <- -y > > 1/y > [1] -Inf > > The other day I came across one in complex numbers, and it took me a > while to figure out that negative zero was what was happening: > > > x <- complex(real = -1) > > x > [1] -1+0i > > 1/x > [1] -1+0i > > x^(1/3) > [1] 0.5+0.8660254i > > (1/x)^(1/3) > [1] 0.5-0.8660254i > > (The imaginary part of 1/x is negative zero.) > > As a Friday question: are there other ways to create and detect > negative zero in R? > > And another somewhat more serious question: is the behaviour of > negative zero consistent across platforms? (The calculations above were > done in Windows in R-devel.) No, I get > 1/ Im(1/complex(real = -1)) [1] Inf > sessionInfo() R version 2.6.0 Under development (unstable) (2007-08-16 r42532) x86_64-unknown-linux-gnu This is on an AMD 64, and I get -Inf on everything else I've tried so far, which are all Intel. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Friday question: negative zero
Seems the same on this Apple Mac OSX platform:
> y <- 0
> 1/y
[1] Inf
> y <- -y
> 1/y
[1] -Inf
> x <- complex(real = -1)
> x
[1] -1+0i
> 1/x
[1] -1+0i
> x^(1/3)
[1] 0.5+0.8660254i
> (1/x)^(1/3)
[1] 0.5-0.8660254i
> sessionInfo()
R version 2.5.1 (2007-06-27)
powerpc-apple-darwin8.9.1
locale:
en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
attached base packages:
[1] "stats" "graphics" "grDevices" "utils" "datasets" "methods"
"base"
> system("uname -a")
Darwin Dapple.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59
PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc
> version
_
platform powerpc-apple-darwin8.9.1
arch powerpc
os darwin8.9.1
system powerpc, darwin8.9.1
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)
Steven McKinney
-Original Message-
From: [EMAIL PROTECTED] on behalf of Duncan Murdoch
Sent: Fri 8/31/2007 5:39 PM
To: R Devel
Subject: [Rd] Friday question: negative zero
The IEEE floating point standard allows for negative zero, but it's hard
to know that you have one in R. One reliable test is to take the
reciprocal. For example,
> y <- 0
> 1/y
[1] Inf
> y <- -y
> 1/y
[1] -Inf
The other day I came across one in complex numbers, and it took me a
while to figure out that negative zero was what was happening:
> x <- complex(real = -1)
> x
[1] -1+0i
> 1/x
[1] -1+0i
> x^(1/3)
[1] 0.5+0.8660254i
> (1/x)^(1/3)
[1] 0.5-0.8660254i
(The imaginary part of 1/x is negative zero.)
As a Friday question: are there other ways to create and detect
negative zero in R?
And another somewhat more serious question: is the behaviour of
negative zero consistent across platforms? (The calculations above were
done in Windows in R-devel.)
Duncan Murdoch
__
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] Friday question: negative zero
On 8/31/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > The IEEE floating point standard allows for negative zero, but it's hard > to know that you have one in R. One reliable test is to take the > reciprocal. For example, > > > y <- 0 > > 1/y > [1] Inf > > y <- -y > > 1/y > [1] -Inf > > The other day I came across one in complex numbers, and it took me a > while to figure out that negative zero was what was happening: > > > x <- complex(real = -1) > > x > [1] -1+0i > > 1/x > [1] -1+0i > > x^(1/3) > [1] 0.5+0.8660254i > > (1/x)^(1/3) > [1] 0.5-0.8660254i > > (The imaginary part of 1/x is negative zero.) > > As a Friday question: are there other ways to create and detect > negative zero in R? I think the only other way is the IEEE CopySign function but I don't think R has implemented it -- R probably should. Google CopySign . __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Friday question: negative zero
The IEEE floating point standard allows for negative zero, but it's hard to know that you have one in R. One reliable test is to take the reciprocal. For example, > y <- 0 > 1/y [1] Inf > y <- -y > 1/y [1] -Inf The other day I came across one in complex numbers, and it took me a while to figure out that negative zero was what was happening: > x <- complex(real = -1) > x [1] -1+0i > 1/x [1] -1+0i > x^(1/3) [1] 0.5+0.8660254i > (1/x)^(1/3) [1] 0.5-0.8660254i (The imaginary part of 1/x is negative zero.) As a Friday question: are there other ways to create and detect negative zero in R? And another somewhat more serious question: is the behaviour of negative zero consistent across platforms? (The calculations above were done in Windows in R-devel.) Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compiling R-devel
[EMAIL PROTECTED] wrote: > Hello. > > I am in a habit of compiling daily snapshots of R-devel and R-patched on my > Windows XP workstation. I have cygwin environment with up-to-date RTools > and MiKTeX. I run cygwin and MiKTeX upadaters pretty often (every couple > of days) so both of them are reasonably current. > > Recently I noticed a small annoyance when compiling R-dvel. It started > happening right after I updated to the new version of RTools (containing > MinGW 4.2.1-sjlj compilers). Everything else stayed the same with possible > exception of MiKTeX update. > > I usually just type "make distribution" to compile everything. The > compilation itself goes smoothly. Then the PDF version of the reference > manual is created. Then I see this: > > ... > Output written on refman.pdf (1563 pages, 7869936 bytes). > Transcript written on refman.log. > creating doc/manual/version.texi > texi2dvi --pdf --texinfo="@set UseExternalXrefs " R-FAQ.texi > This is pdfTeX, Version 3.141592-1.40.4 (MiKTeX 2.6) > entering extended mode > ! I can't find file `\tmp\t2d6036\xtr\R-FAQ.texi'. > <*> /tmp/t2d6036/xtr/R-FAQ.texi > > Please type another input file name: > > Now the file /tmp/t2d6036/xtr/R-FAQ.texi exists at this point is not empty > and has usual protection codes. I tried different versions of back and > front slashes, double backslashes, etc., but to no avail. I was getting > the same message - the file cannot be found. The only thing that works is > the plain file name. That is, if I just type (or copy and paste) the > string R-FAQ.texi everything works fine. This happens three times for > every manual (except the refman). After that the compilation ends > normally, the windows installer is created and, when I run the installer, I > get everything working correctly including PDFs of the manuals. > > It looks to me like the /tmp/t2d6036/xtr/ part of the name gets already > pre-pended to whatever name the make process provides so it expects just > the file name. Alternatively, something changed in my MiKTeX setup due to > updates. However, the refman compiles properly and I can also compile > other LaTeX with no apparent problems. > > Thanks in advance, How do you have your temp directory set? I'm not sure if it's R or one of the build tools that's important here, so it's worth looking at all environment variables TMPDIR, TEMP, TMP, etc. Are you running the build in Cygwin, or in a Windows CMD window? I use Cygwin (not quite so current as yours) and don't see this error. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ****R 2.6.0**** scheduled for October 3
D'oh! There's always one more item to update Peter Dalgaard wrote: > This is to announce that we plan to release R version 2.6.0 on Wednesday > October 3, 2007. The following information is mainly for developers, > package maintainers and repository maintainers. > > The planned procedure is > > Sep 5: "Grand Feature" Freeze 2.6.0 alpha > Sep 19: Feature Freeze 2.6.0 beta > Sep 26: Code Freeze 2.6.0 RC > Oct 3: Release 2.6.0 > > GFF: No major restructuring past this point > FF: Feature set complete, only bugfixing from now on > CF: Only critical bugfixes and platform build issues > > Maintainers of recommended packages should notice that as they become > part of the final R tarball, we expect them to follow a similar freeze > pattern (and beware of potential CRAN delays, so please do not cut it > too close to the deadlines). > > Notice that the main structural discontinuities occurs at GFF: > > The SVN repository is affected as follows > The trunk version is set to "2.7.0 Under development (unstable)". > A new branch, R-2-7-branch is created. > > This also implies new version numbers for "r-devel" and > "r-release-branch", in the sense of > > http://developer.r-project.org/SVNtips.html > > Also, "r-release-branch" needs to have its tag updated. > > Repository maintainers may need to revise directory structures > accordingly. > > "R 2.5.1 Patched" will be closed to further development at GFF (as all > the release branches, it can be reopened if the need arises, we just > don't anticipate such a need.) > > The source alpha/beta/RC tarballs will be made available daily > (barring build troubles) by a cron job running at 4AM CET, and the > tarballs can be picked up at > > http://cran.r-project.org/src/base-prerelease/ > > a little later. > > The various freeze points are marked by changes to the VERSION file > this is also done automatically by a cron job which runs just after > midnight on the relevant days. > > -- 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] compiling R-devel
Hello. I am in a habit of compiling daily snapshots of R-devel and R-patched on my Windows XP workstation. I have cygwin environment with up-to-date RTools and MiKTeX. I run cygwin and MiKTeX upadaters pretty often (every couple of days) so both of them are reasonably current. Recently I noticed a small annoyance when compiling R-dvel. It started happening right after I updated to the new version of RTools (containing MinGW 4.2.1-sjlj compilers). Everything else stayed the same with possible exception of MiKTeX update. I usually just type "make distribution" to compile everything. The compilation itself goes smoothly. Then the PDF version of the reference manual is created. Then I see this: ... Output written on refman.pdf (1563 pages, 7869936 bytes). Transcript written on refman.log. creating doc/manual/version.texi texi2dvi --pdf --texinfo="@set UseExternalXrefs " R-FAQ.texi This is pdfTeX, Version 3.141592-1.40.4 (MiKTeX 2.6) entering extended mode ! I can't find file `\tmp\t2d6036\xtr\R-FAQ.texi'. <*> /tmp/t2d6036/xtr/R-FAQ.texi Please type another input file name: Now the file /tmp/t2d6036/xtr/R-FAQ.texi exists at this point is not empty and has usual protection codes. I tried different versions of back and front slashes, double backslashes, etc., but to no avail. I was getting the same message - the file cannot be found. The only thing that works is the plain file name. That is, if I just type (or copy and paste) the string R-FAQ.texi everything works fine. This happens three times for every manual (except the refman). After that the compilation ends normally, the windows installer is created and, when I run the installer, I get everything working correctly including PDFs of the manuals. It looks to me like the /tmp/t2d6036/xtr/ part of the name gets already pre-pended to whatever name the make process provides so it expects just the file name. Alternatively, something changed in my MiKTeX setup due to updates. However, the refman compiles properly and I can also compile other LaTeX with no apparent problems. Thanks in advance, Andy __ Andy Jaworski 518-1-01 Process Laboratory 3M Corporate Research Laboratory - E-mail: [EMAIL PROTECTED] Tel: (651) 733-6092 Fax: (651) 736-3122 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Consistency of serialize(): please enlighten me
Forgot...
On 8/31/07, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am puzzled with serialize(). It comes down generating identical
> hash codes for (apparently) identical objects using digest::digest(),
> which in turn relies on serialize(). Here is an example illustration
> the issue:
>
> ser <- function(object, ...) {
> list(
> names = names(object),
> namesRaw = charToRaw(names(object)),
> ser = serialize(names(object), connection=NULL, ascii=FALSE)
> )
> } # ser()
>
> # Object to be serialized
> key <- key0 <- list(abc="Hello");
>
> # Store results
> d <- list();
>
> # 1. As is
> d[[1]] <- ser(key);
>
> # 2. Set names and redo (hardwired: identical to what's already there)
> names(key) <- "abc";
> d[[2]] <- ser(key);
>
> # 3. Set names and redo (generic: char->raw->char)
> key <- key0;
> names(key) <- sapply(names(key), FUN=function(name)
> rawToChar(charToRaw(name)));
> d[[3]] <- ser(key);
>
> # All names are identical
> for (kk in 2:length(d))
> stopifnot(identical(d[[1]]$names, d[[kk]]$names));
>
> # All raw names are identical
> for (kk in 2:length(d))
> stopifnot(identical(d[[1]]$namesRaw, d[[kk]]$namesRaw));
>
> # But, the serialized names differ.
> print(identical(d[[1]]$ser, d[[2]]$ser));
> print(identical(d[[1]]$ser, d[[3]]$ser));
> print(identical(d[[2]]$ser, d[[3]]$ser));
With R version 2.6.0 Under development (unstable) (2007-08-23 r42614) I get:
[1] TRUE
[1] FALSE
[1] FALSE
and with R version 2.5.1 Patched (2007-07-19 r42284):
[1] FALSE
[1] FALSE
[1] TRUE
>
> So, it seems like there is some extra information in the names
> attribute that is part of the serialization. Is it possible to show
> they differ at the R level? What is that extra information?
> Promises...?
>
> Please enlighten me.
>
> Henrik
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Consistency of serialize(): please enlighten me
Hi,
I am puzzled with serialize(). It comes down generating identical
hash codes for (apparently) identical objects using digest::digest(),
which in turn relies on serialize(). Here is an example illustration
the issue:
ser <- function(object, ...) {
list(
names = names(object),
namesRaw = charToRaw(names(object)),
ser = serialize(names(object), connection=NULL, ascii=FALSE)
)
} # ser()
# Object to be serialized
key <- key0 <- list(abc="Hello");
# Store results
d <- list();
# 1. As is
d[[1]] <- ser(key);
# 2. Set names and redo (hardwired: identical to what's already there)
names(key) <- "abc";
d[[2]] <- ser(key);
# 3. Set names and redo (generic: char->raw->char)
key <- key0;
names(key) <- sapply(names(key), FUN=function(name) rawToChar(charToRaw(name)));
d[[3]] <- ser(key);
# All names are identical
for (kk in 2:length(d))
stopifnot(identical(d[[1]]$names, d[[kk]]$names));
# All raw names are identical
for (kk in 2:length(d))
stopifnot(identical(d[[1]]$namesRaw, d[[kk]]$namesRaw));
# But, the serialized names differ.
print(identical(d[[1]]$ser, d[[2]]$ser));
print(identical(d[[1]]$ser, d[[3]]$ser));
print(identical(d[[2]]$ser, d[[3]]$ser));
So, it seems like there is some extra information in the names
attribute that is part of the serialization. Is it possible to show
they differ at the R level? What is that extra information?
Promises...?
Please enlighten me.
Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] locales and readLines
R-developers,
I'm looking for some 'best practices', or perhaps an upstream solution
(I have a deja vu about this, so sorry if it's already been asked).
Problems occur when a file is encoded as latin1, but the user has a
UTF-8 locale (or I guess more generally when the input locale does not
match R's). Here are two examples from the Bioconductor help list:
https://stat.ethz.ch/pipermail/bioconductor/2007-August/018947.html
(the relevant command is library(GEOquery); gse <- getGEO('GSE94'))
https://stat.ethz.ch/pipermail/bioconductor/2007-July/018204.html
I think solutions are:
* Specify the encoding in readLines.
* Convert the input using iconv.
* Tell the user to set their locale to match the input file (!)
Unfortunately, these (1 & 2, anyway) place extra burden on the package
author, to become educated about locales, the encoding conventions of
the files they read, and to know how R deals with encodings.
Are there other / better solutions? Any chance for some (additional)
'smarts' when reading files?
Martin
--
Martin Morgan
Bioconductor / Computational Biology
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Plans for multithreading?
On Fri, 31 Aug 2007, D. R. Evans wrote: > I was surprised, given the vector-ish nature of R, to see that > (according to my CPU meters) there doesn't seem to be any obvious > multithreading in R. > > Are there any plans to change this? Yes, and some multithreading is done with some external BLAS, which is probably where there is the most obvious scope for benefit. The problem is that unless the vectors are long the costs of using multiple threads can exceed the gain in using multiple CPUs: we have seen dramatic slowdowns using reputable multithreaded BLAS. Other parts of R are under active consideration for using multiple threads: for example now Open MP is fairly widely available (in gcc >= 4.2.0 and some earlier RedHat backports) this may be easier to do in a portable way. I think you probably did not mean the ability to run multiple R interpreters in separate threads -- that has been discussed for many years (e.g. at DSC 2001). -- 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] R CMD check recursive copy of tests/
"Henrik Bengtsson" <[EMAIL PROTECTED]> writes: >> intentional I'd say: I did not implement it, but it seems much >> more logical to keep the previous rule: All *.R files in >> ./tests/ are run >> Subdirectories can be useful for organization, notably storing >> test data. I don't think it's a good idea to use so very many test files >> that you need subdirectories, unless maybe you are thinking >> about unit tests; and then, see below. > > Examples of subdirectories (some overlapping) are: > > units/ - tests of minimal code modules > integration/ - tests of integrating the above units > system/ - "real-world" scenarios/use cases > > requirements/ - every requirement should have at least on test. > bugs/ - every bug fix should come with a new test. > regression/ - every update should have a regression test to validate > backward compatibility etc. > > robustness/ - Testing the robustness of estimators against outliers as > well as extreme parameter settings. > validation/ - validation of numeric results compared with alternative > implementations or summaries. > > benchmarking/ - actually more measuring time, but can involve > validation that a method is faster than an alternative. > crossplatform/ - validate correctness across platforms. > torture/ - pushing the limits. Those all seem like reasonable examples, but the fact that R CMD check doesn't recurse really isn't a problem. You can have a driver script at the top-level that runs as many of the tests in subdirs as you want. And this is really a good thing since as you mentioned later in your response, some tests take a long time to run and probably are best not automatically run during R CMD check. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center BioC: http://bioconductor.org/ Blog: http://userprimary.net/user/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Plans for multithreading?
I was surprised, given the vector-ish nature of R, to see that (according to my CPU meters) there doesn't seem to be any obvious multithreading in R. Are there any plans to change this? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
