Re: [Rd] cygwin R-2.14.0 build fail
On 11/12/2011 3:25 PM, Mark Carter wrote: I tried to build R-2.14.0 on cygwin using the commands: ./configure --with-x=no make I started to get a whole lot of errors starting with: /cygdrive/c/Users/mcarter/src/R-2.14.0/src/modules/internet/Rhttpd.c:275: undefined reference to `_R_InputHandlers' which I have pasted at http://pastebin.com/GFb2pq92 I'm aware that there is a cygwinports ports, but it seems outdated, and when I tried installing it, it was very lengthy and seemed more trouble that it was worth. I abandoned the installation attempt. Any tips on a way forward? just built R-2.14.0 deriving from R-2.13.1-1 of cygport. configure --with-blas=$(pkg-config --libs blas) \ --with-lapack \ --enable-R-shlib \ TCLTK_LIBS=-ltcl84 -ltk84 \ --with-system-zlib \ --with-system-bzlib \ --with-system-pcre \ --with-system-xz \ --disable-openmp almost all test passed $ grep OK R-2.14.0-1-check.log |wc -l 57 only 3 minor failures $ find ../build/ -name *fail ../build/tests/Examples/parallel-Ex.Rout.fail ../build/tests/reg-BLAS.Rout.fail ../build/tests/reg-IO.Rout.fail If you are interested I can provide you the binary package. Regards Marco __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Injecting source reference from external editors (emacs).
Hi everyone,
I would like to inject source reference into R objects from external editor. In
my case it's emacs with ESS and ess-tracebug
(http://code.google.com/p/ess-tracebug/).
Currently the user has to source the file before the src references become
available. I would like to spare her, and insert the source references on-line
during normal interaction (i.e. sending chunks of code from emacs buffers)
With new additions in R-14 I started looking into it and discovered that an
encapsulation
eval(parse(text = tf - function(a){a^5
b - a;
return(b)
}, srcfile = srcfile(@buffer@)))
does quite a good job, and the debugger would display something like:
Browse[2] debug at @buffer@#2: b - a
Browse[2] debug at @buffer@#3: return(b)
which is great, and could be used for what I want.
The problem is that I have to interfere with the user's input, which might not
be a good idea always. Is there (will be?) a more direct way of doing
this without encapsulation?
Currently when a function tf-function(a){a^5} is created at R
prompt, R associates
with it a srcref with empty srcfile reference.
I wonder if it would be possible to instruct R that next evaluation will be from
buffer Xbuf at line N, something like
setSrcSource(srcobject=buffX, srcline=45)
so that any input that follows, would get a srcref pointing to buffX starting
from line 45 instead of just empty reference?
At the end of the evaluation I would just reset R with
setSrcSource(NULL)
Thanks,
Vitalie.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question on parsing R code from C
Simon Urbanek simon.urbanek at r-project.org writes: Not without seeing the actual code. (And details such as which platform you're on). Note that setup_Rmainloop() is the last to set the SETJMP context target so you should make sure the stack is still present after it finished (i.e. you can't call it from a sub-function - which Rf_initEmbeddedR does) otherwise error without an enclosing context will crash. Or to put it other way round, create a context around your parse/eval code (probably the easiest way to do that is to use R_ToplevelExec). I will try to produce the exact code I am using (at the moment it embedded in other code you would not be interested in), platforms are Windows XP and Windows7-64. Some points: 1. Actually R_tryEvalSilent (and R_tryEval) calls R_ToplevelExec. Moreover if the problem is linked to the SETJMP (which I do not know much about unfortunately, my background is C++) it's my understanding that it should manifest itself even for other parse and evaluation errors. Instead the problem arise if and only if I pass a wrongly escaped string. I.e. rnorm(10a10) does not result in a crash. Is the R code doing something differently in this specific case? 2. My code is almost exactly the same as: http://stackoverflow.com/questions/2463437/r-from-c-simplest-possible- helloworld/2464479#2464479 skipping the EXAMPLE 1 part and passing the capture.output(eval(parse(text= code))) string to R_tryEval in EXAMPLE 2. Cheers, __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Question on parsing R code from C
On Nov 16, 2011, at 2:48 PM, KR wrote: Simon Urbanek simon.urbanek at r-project.org writes: Not without seeing the actual code. (And details such as which platform you're on). Note that setup_Rmainloop() is the last to set the SETJMP context target so you should make sure the stack is still present after it finished (i.e. you can't call it from a sub-function - which Rf_initEmbeddedR does) otherwise error without an enclosing context will crash. Or to put it other way round, create a context around your parse/eval code (probably the easiest way to do that is to use R_ToplevelExec). I will try to produce the exact code I am using (at the moment it embedded in other code you would not be interested in), platforms are Windows XP and Windows7-64. Some points: 1. Actually R_tryEvalSilent (and R_tryEval) calls R_ToplevelExec. Yes, but that's not where you get the crash. Moreover if the problem is linked to the SETJMP (which I do not know much about unfortunately, my background is C++) it's my understanding that it should manifest itself even for other parse and evaluation errors. Instead the problem arise if and only if I pass a wrongly escaped string. I.e. rnorm(10a10) does not result in a crash. Is the R code doing something differently in this specific case? Your crash is in the parsing step, not in the evaluator (if I understand you correctly) and the parsing step is not wrapped in a context - that's my guess based on what you told us. Cheers, Simon 2. My code is almost exactly the same as: http://stackoverflow.com/questions/2463437/r-from-c-simplest-possible- helloworld/2464479#2464479 skipping the EXAMPLE 1 part and passing the capture.output(eval(parse(text= code))) string to R_tryEval in EXAMPLE 2. Cheers, __ 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] cygwin R-2.14.0 build fail
The failures are *not* minor. Please don't distribute an R linked to a broken BLAS library. Those tests are not for fun: they came from real errors on real problems. On Wed, 16 Nov 2011, marco atzeri wrote: On 11/12/2011 3:25 PM, Mark Carter wrote: I tried to build R-2.14.0 on cygwin using the commands: ./configure --with-x=no make I started to get a whole lot of errors starting with: /cygdrive/c/Users/mcarter/src/R-2.14.0/src/modules/internet/Rhttpd.c:275: undefined reference to `_R_InputHandlers' which I have pasted at http://pastebin.com/GFb2pq92 I'm aware that there is a cygwinports ports, but it seems outdated, and when I tried installing it, it was very lengthy and seemed more trouble that it was worth. I abandoned the installation attempt. Any tips on a way forward? just built R-2.14.0 deriving from R-2.13.1-1 of cygport. configure --with-blas=$(pkg-config --libs blas) \ --with-lapack \ --enable-R-shlib \ TCLTK_LIBS=-ltcl84 -ltk84 \ --with-system-zlib \ --with-system-bzlib \ --with-system-pcre \ --with-system-xz \ --disable-openmp almost all test passed $ grep OK R-2.14.0-1-check.log |wc -l 57 only 3 minor failures $ find ../build/ -name *fail ../build/tests/Examples/parallel-Ex.Rout.fail ../build/tests/reg-BLAS.Rout.fail ../build/tests/reg-IO.Rout.fail If you are interested I can provide you the binary package. Regards Marco __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] cygwin R-2.14.0 build fail
On 11/16/2011 9:32 PM, Prof Brian Ripley wrote: The failures are *not* minor. Please don't distribute an R linked to a broken BLAS library. Those tests are not for fun: they came from real errors on real problems. Dear Brian, I am reasonable sure that the cygwin blas library are fine, have you any evidence that they are broken ? The R test log just reports an issue handling NA that could be related to cygwin difference to others platform. I already noted similar difference on cygwin octave package. Here is the log: -- ## PR#4582 %*% with NAs stopifnot(is.na(NA %*% 0), is.na(0 %*% NA)) ## depended on the BLAS in use. ## found from fallback test in slam 0.1-15 ## most likely indicates an inaedquate BLAS. x - matrix(c(1, 0, NA, 1), 2, 2) y - matrix(c(1, 0, 0, 2, 1, 0), 3, 2) (z - tcrossprod(x, y)) [,1] [,2] [,3] [1,] NA NA0 [2,]210 stopifnot(identical(z, x %*% t(y))) Error: identical(z, x %*% t(y)) is not TRUE Execution halted tests/reg-BLAS.Rout.fail (END) -- Regards Marco __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] strange behavior from cex=*
Someone inquired on StackOverflow about apparently non-deterministic
graphics behaviour in R. I noticed that they were using cex=* and
discovered some potentially weird behavior.
On repeated runs of the same code I can get different PNGs. If I set
the number of runs high enough, I seem to be able to get R to hang.
If I do a single version plotting to an interactive graphics window I
can get the point sizes to jump around as I resize the window (someone
reported being able to reproduce that behaviour in the Windows GUI as well).
This is clearly a user error, but non-deterministic behaviour (and
hanging) are a little disturbing.
I haven't had a chance yet to try to dig in and see what's happening
but thought I would report to see if anyone else could reproduce/figure
it out.
Ben Bolker
## n - 100 ## hangs R
n - 33
fn - paste(tmp,seq(n),png,sep=.)
for (i in seq(n)) {
png(fn[i])
plot(1:10,1:10,cex=*);
dev.off()
}
ff - subset(file.info(fn),select=size)
ff - ff[!duplicated(ff$size),,drop=FALSE]
table(ff$size)
require(png)
pngs - lapply(rownames(ff),readPNG)
png.to.img - function(x) matrix(rgb(x[,,1],x[,,2],x[,,3]),
nrow=dim(x)[1],ncol=dim(x)[2])
imgs - lapply(pngs,png.to.img)
par(mfrow=c(2,2))
lapply(imgs,function(x) {
plot(0:1,0:1,type=n,ann=FALSE,axes=FALSE)
rasterImage(x,0,0,1,1)
})
#
sessionInfo()
R Under development (unstable) (2011-10-06 r57181)
Platform: i686-pc-linux-gnu (32-bit)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] glmmADMB_0.6.5 MASS_7.3-14png_0.1-3
loaded via a namespace (and not attached):
[1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102tools_2.15.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cygwin R-2.14.0 build fail
On Nov 16, 2011, at 22:08 , marco atzeri wrote: On 11/16/2011 9:32 PM, Prof Brian Ripley wrote: The failures are *not* minor. Please don't distribute an R linked to a broken BLAS library. Those tests are not for fun: they came from real errors on real problems. Dear Brian, I am reasonable sure that the cygwin blas library are fine, have you any evidence that they are broken ? The R test log just reports an issue handling NA that could be related to cygwin difference to others platform. I already noted similar difference on cygwin octave package. Well, on other platforms we have tcrossprod(x,y) [,1] [,2] [,3] [1,] NA NA NA [2,]210 x %*% t(y) [,1] [,2] [,3] [1,] NA NA NA [2,]210 so the Cygwin tcrossprod is implicitly letting 0*NA==0 (in the DGEMM BLAS routine). This is not what should happen according to the standards, and there are people whose code relies on standards compliance (and that's why the test is there). It's also plain wrong, because in extended arithmetic, the missing value could be Inf, and 0*Inf == NaN, so assuming that 0*anything==0 doesn't work. -pd Here is the log: -- ## PR#4582 %*% with NAs stopifnot(is.na(NA %*% 0), is.na(0 %*% NA)) ## depended on the BLAS in use. ## found from fallback test in slam 0.1-15 ## most likely indicates an inaedquate BLAS. x - matrix(c(1, 0, NA, 1), 2, 2) y - matrix(c(1, 0, 0, 2, 1, 0), 3, 2) (z - tcrossprod(x, y)) [,1] [,2] [,3] [1,] NA NA0 [2,]210 stopifnot(identical(z, x %*% t(y))) Error: identical(z, x %*% t(y)) is not TRUE Execution halted tests/reg-BLAS.Rout.fail (END) -- Regards Marco __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex=*
Hi Ben,
Just a few things to add.
First, the same phenomenon occurs when you use any character string as
the value of cex; there is nothing special about *.
Second, you cannot get this phenomenon by trying to do something like
par(cex=*)
because the par function actually checks if the value is a nonnegative
number.
Finally, producing the different graphs is clearly occuring inside the
plot.xy function, although I have not yet caused R2.14 to hang. This
at least suggests a fix: make sure that plot.xy checks the type of the
cex argument in the same way that par does.
Kevin
###
xy - xy.coords(1:10, 1:10)
plot(xy)
for(i in seq(100)) plot.xy(xy, p, cex=*, col=i)
###
sessionInfo()
R version 2.14.0 (2011-10-31)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] png_0.1-3
loaded via a namespace (and not attached):
[1] tools_2.14.0
On 11/16/2011 3:38 PM, Ben Bolker wrote:
Someone inquired on StackOverflow about apparently non-deterministic
graphics behaviour in R. I noticed that they were using cex=* and
discovered some potentially weird behavior.
On repeated runs of the same code I can get different PNGs. If I set
the number of runs high enough, I seem to be able to get R to hang.
If I do a single version plotting to an interactive graphics window I
can get the point sizes to jump around as I resize the window (someone
reported being able to reproduce that behaviour in the Windows GUI as well).
This is clearly a user error, but non-deterministic behaviour (and
hanging) are a little disturbing.
I haven't had a chance yet to try to dig in and see what's happening
but thought I would report to see if anyone else could reproduce/figure
it out.
Ben Bolker
## n- 100 ## hangs R
n- 33
fn- paste(tmp,seq(n),png,sep=.)
for (i in seq(n)) {
png(fn[i])
plot(1:10,1:10,cex=*);
dev.off()
}
ff- subset(file.info(fn),select=size)
ff- ff[!duplicated(ff$size),,drop=FALSE]
table(ff$size)
require(png)
pngs- lapply(rownames(ff),readPNG)
png.to.img- function(x) matrix(rgb(x[,,1],x[,,2],x[,,3]),
nrow=dim(x)[1],ncol=dim(x)[2])
imgs- lapply(pngs,png.to.img)
par(mfrow=c(2,2))
lapply(imgs,function(x) {
plot(0:1,0:1,type=n,ann=FALSE,axes=FALSE)
rasterImage(x,0,0,1,1)
})
#
sessionInfo()
R Under development (unstable) (2011-10-06 r57181)
Platform: i686-pc-linux-gnu (32-bit)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] glmmADMB_0.6.5 MASS_7.3-14png_0.1-3
loaded via a namespace (and not attached):
[1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102tools_2.15.0
__
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] strange behavior from cex=*
On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
Someone inquired on StackOverflow about apparently non-deterministic
graphics behaviour in R. I noticed that they were using cex=* and
discovered some potentially weird behavior.
It can be reproduced much more simply (well, not the hang, but bad enough):
In a plain R application console (OSX Snow Leopard),
for (i in 1:100) plot(1:10,cex=*)
will _sometimes_ show big circles, indicating random data being picked up.
The cex is by definition numeric, so you can't expect to be able to pass a
character string, but the code should check.
On repeated runs of the same code I can get different PNGs. If I set
the number of runs high enough, I seem to be able to get R to hang.
If I do a single version plotting to an interactive graphics window I
can get the point sizes to jump around as I resize the window (someone
reported being able to reproduce that behaviour in the Windows GUI as well).
This is clearly a user error, but non-deterministic behaviour (and
hanging) are a little disturbing.
I haven't had a chance yet to try to dig in and see what's happening
but thought I would report to see if anyone else could reproduce/figure
it out.
Ben Bolker
## n - 100 ## hangs R
n - 33
fn - paste(tmp,seq(n),png,sep=.)
for (i in seq(n)) {
png(fn[i])
plot(1:10,1:10,cex=*);
dev.off()
}
ff - subset(file.info(fn),select=size)
ff - ff[!duplicated(ff$size),,drop=FALSE]
table(ff$size)
require(png)
pngs - lapply(rownames(ff),readPNG)
png.to.img - function(x) matrix(rgb(x[,,1],x[,,2],x[,,3]),
nrow=dim(x)[1],ncol=dim(x)[2])
imgs - lapply(pngs,png.to.img)
par(mfrow=c(2,2))
lapply(imgs,function(x) {
plot(0:1,0:1,type=n,ann=FALSE,axes=FALSE)
rasterImage(x,0,0,1,1)
})
#
sessionInfo()
R Under development (unstable) (2011-10-06 r57181)
Platform: i686-pc-linux-gnu (32-bit)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] glmmADMB_0.6.5 MASS_7.3-14png_0.1-3
loaded via a namespace (and not attached):
[1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102tools_2.15.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex=*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-11-16 05:18 PM, peter dalgaard wrote:
On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
Someone inquired on StackOverflow about apparently non-deterministic
graphics behaviour in R. I noticed that they were using cex=* and
discovered some potentially weird behavior.
It can be reproduced much more simply (well, not the hang, but bad enough):
In a plain R application console (OSX Snow Leopard),
for (i in 1:100) plot(1:10,cex=*)
will _sometimes_ show big circles, indicating random data being picked up.
The cex is by definition numeric, so you can't expect to be able to pass a
character string, but the code should check.
Looks (?) like the check could go in FixupCex (which already tests for
isReal, isInteger, and isLogical) in src/main/plot.c , unless there is a
wish to catch it earlier/in R code.
It's mildly surprising to me that people can continue to find odd
cases like this after more than 10 years (and imagine how many
cumulative hours of R use ...) [I'm assuming that this hole has been
present for a log time: I don't have the patience to do the SVN
archaeology to find out how long.]
On repeated runs of the same code I can get different PNGs. If I set
the number of runs high enough, I seem to be able to get R to hang.
If I do a single version plotting to an interactive graphics window I
can get the point sizes to jump around as I resize the window (someone
reported being able to reproduce that behaviour in the Windows GUI as well).
This is clearly a user error, but non-deterministic behaviour (and
hanging) are a little disturbing.
I haven't had a chance yet to try to dig in and see what's happening
but thought I would report to see if anyone else could reproduce/figure
it out.
Ben Bolker
## n - 100 ## hangs R
n - 33
fn - paste(tmp,seq(n),png,sep=.)
for (i in seq(n)) {
png(fn[i])
plot(1:10,1:10,cex=*);
dev.off()
}
ff - subset(file.info(fn),select=size)
ff - ff[!duplicated(ff$size),,drop=FALSE]
table(ff$size)
require(png)
pngs - lapply(rownames(ff),readPNG)
png.to.img - function(x) matrix(rgb(x[,,1],x[,,2],x[,,3]),
nrow=dim(x)[1],ncol=dim(x)[2])
imgs - lapply(pngs,png.to.img)
par(mfrow=c(2,2))
lapply(imgs,function(x) {
plot(0:1,0:1,type=n,ann=FALSE,axes=FALSE)
rasterImage(x,0,0,1,1)
})
#
sessionInfo()
R Under development (unstable) (2011-10-06 r57181)
Platform: i686-pc-linux-gnu (32-bit)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] glmmADMB_0.6.5 MASS_7.3-14png_0.1-3
loaded via a namespace (and not attached):
[1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102tools_2.15.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOxDiKAAoJED2whTVMEyK9ThoIAIjyMpzZqsjUpJVbAb9K8IrL
LbSFh8zb+cZb90ABkFwJaZ2FNTKCjPrUzOYzxxHuU9AY0bdPQGbIm2hvQfzcuMlc
urS/ILIMzZEFSYkqkj0mWI9SADyJ+W0YeN/t3EuWy8nZqUkYQZ8M0GsuXjhtUL/i
hVJU0uuIWCOCHpeI3SQKoxviTE6MQFRXXWhCAJx01h8ee/5UQ5GSGB7Er2Zilld3
0sLI6dmoF7gbeYqz33MaEpQ7geJoW3tfnVbQWUlF86+jGGv5trIqWYIp33OYIxMO
u2YUq51vB+4uIRPFJ4Oyr+nJF0Z9NH4IJBipp/bF6wQ5u6JdXFqKTPeQ1V6m5qk=
=YajM
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex=*
On Wed, Nov 16, 2011 at 11:26 PM, Ben Bolker bbol...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's mildly surprising to me that people can continue to find odd cases like this after more than 10 years (and imagine how many cumulative hours of R use ...) Mildly surprising? It's astonishing once you realize that for more than 10 years people were actually using the cex argument as intended. There is hope for mankind after all... :-) -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cygwin R-2.14.0 build fail
On 11/16/2011 11:04 PM, peter dalgaard wrote: On Nov 16, 2011, at 22:08 , marco atzeri wrote: On 11/16/2011 9:32 PM, Prof Brian Ripley wrote: The failures are *not* minor. Please don't distribute an R linked to a broken BLAS library. Those tests are not for fun: they came from real errors on real problems. Dear Brian, I am reasonable sure that the cygwin blas library are fine, have you any evidence that they are broken ? The R test log just reports an issue handling NA that could be related to cygwin difference to others platform. I already noted similar difference on cygwin octave package. Well, on other platforms we have tcrossprod(x,y) [,1] [,2] [,3] [1,] NA NA NA [2,]210 x %*% t(y) [,1] [,2] [,3] [1,] NA NA NA [2,]210 so the Cygwin tcrossprod is implicitly letting 0*NA==0 (in the DGEMM BLAS routine). This is not what should happen according to the standards, and there are people whose code relies on standards compliance (and that's why the test is there). It's also plain wrong, because in extended arithmetic, the missing value could be Inf, and 0*Inf == NaN, so assuming that 0*anything==0 doesn't work. -pd I presume it is a netlib DGEMM issue and not a specific cygwin port issue. There is an optimization on the reference implementation: http://www.netlib.org/lapack/explore-html/d7/d2b/dgemm_8f_source.html 00314 IF (B(L,J).NE.ZERO) THEN that fool any 0*NaN or 0*Inf case I noticed it was highlighted on octave mailing list long time ago: http://octave.1599824.n4.nabble.com/NaN-problem-td1662846.html Time to rise the bug with netlib guys ? Regards Marco __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] inaccuracy in man page for duplicated() + anyDuplicated() not working with MARGIN=0
Hi, In man page for duplicated: Value: ‘duplicated()’: For a vector input, a logical vector of the same length as ‘x’. For a data frame, a logical vector with one element for each row. For a matrix or array, a logical array with the same dimensions and dimnames. When 'x' is a matrix or array, the returned value is NOT a logical array: m - matrix(c(3,2,7,6,2,7), nrow=3) m [,1] [,2] [1,]36 [2,]22 [3,]77 duplicated(m) [1] FALSE FALSE FALSE Only if MARGIN=0 it seems: duplicated(m, MARGIN=0) [,1] [,2] [1,] FALSE FALSE [2,] FALSE TRUE [3,] FALSE TRUE Also, any reason why this doesn't work? anyDuplicated(m, MARGIN=0) Error in dim(newX) - c(prod(d.call), d2) : dims [product 1] do not match the length of object [6] May be it could be equivalent to: anyDuplicated(as.vector(m)) [1] 5 Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
