[Rd] Unable to reload Rdoc
Dear list,
I'm hoping the R guru's can help with an error i've been getting for at least a
year during active package development.
I have a package loaded & spot a documentation bug, so I:
edit the Rd file (or in the roxygen header + roxygenize); then
R CMD BUILD,
R CMD INSTALL
then in the same R session, reload the library & lookup a man page, I always
get this error:
Error in fetch(key) : internal error -3 in R_decompress1
I've tried all ways of reloading the package that i'm aware of:
detach then library
unloadNamespace then library
devtools::install
devtools::reload
all lead to the error.
I see from ?detach:
... So detaching and re-attaching a package may
not refresh some or all components of the package, and is
inadvisable.
restarting the R session results in loading the updated man file, but do you
have any ideas how to word around this & continue within the same R session?
cheers,
Mark
# 1) using Hadley's devtools
> library(devtools)
> library(updateR) # my package under development
> install("~/src/R/updateR")
> install("~/src/R/updateR")
Installing updateR
* checking for file /Users/marcow/src/R/updateR/DESCRIPTION ... OK
* preparing updateR:
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building updateR_1.0.4.tar.gz
Warning in normalizePath(c(new, .Library.site, .Library), "/") :
path[3]="": No such file or directory
* installing *source* package updateR ...
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
* DONE (updateR)
Reloading installed updateR
> ?get.full.path
Error in fetch(key) : internal error -3 in R_decompress1
2) using detach + library
$ R --vanilla
library(updateR)
# ?list.my.packages
detach(pos=2, unload=TRUE, force=TRUE)
# <>
system("cd ~/src/R && R CMD BUILD updateR && R CMD INSTALL updateR")
library("updateR")
?list.my.packages
Error in fetch(key) : internal error -3 in R_decompress1
3) using unloadNamespace
$ R --vanilla
library(updateR)
# ?list.my.packages
unloadNamespace("updateR")
# <>
system("cd ~/src/R && R CMD BUILD updateR && R CMD INSTALL updateR")
library("updateR")
?list.my.packages
Error in fetch(key) : internal error -3 in R_decompress1
> sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_AU.UTF-8/en_AU.UTF-8/C/C/en_AU.UTF-8/en_AU.UTF-8
attached base packages:
[1] tools stats graphics grDevices datasets utils methods
[8] base
other attached packages:
[1] updateR_1.0.4 codetools_0.2-8 devtools_0.4
loaded via a namespace (and not attached):
[1] RCurl_1.6-7
-
Mark Cowley, PhD
Pancreatic Cancer Program | Peter Wills Bioinformatics Centre
Garvan Institute of Medical Research, Sydney, Australia
-
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serialize/unserialize vector improvement
On 22/01/2012 13:56, Prof Brian Ripley wrote:
This has languished for a long time, and we should make a decision
before FF for 2.15.0.
It seems to me that in so far as there is a problem, it is that we
serialize via XDR, and that since that was invented little-endian CPUs
have taken over the world. So for the only cases I can imagine this is
really a problem (passing objects in 'parallel'/snow ... contexts) a
better answer might be to pass without byte-reordering: go back to the
RDB format which was exposed for save() but AFAIK never for serialize.
I would say Sparc is the only big-endian platform left (some PPC Mac
users may disagree), so little-endian really does rule.
This does all seem to depend on the quality of the platform's XDR
implementation: for example, a similar example runs twice as fast on
x86_64 Mac OS X as on i386 R on the same machine.
On all the (little-endian) platforms I tried not using XDR
(serialize(xdr = FALSE)) made an improvement of around 3x. On some a
version of Spiegel's patch helped equally and on others it made a much
smaller improvement. In the best-case scenario (i386 OS X) there was a
10x improvement. But that is only going to be noticeable in rare
applications.
A version of Spiegel's idea (with changes confined to just one file)
will appear in R-devel shortly.
Brian
On 03/10/2011 14:28, luke-tier...@uiowa.edu wrote:
It's on my list to look at but I may not get to it for a couple of
weeks. Someone else may get there earlier.
Best,
luke
On Mon, 3 Oct 2011, Michael Spiegel wrote:
Any thoughts? I haven't heard any feedback on this patch.
Thanks!
--Michael
On Wed, Sep 28, 2011 at 3:10 PM, Michael Spiegel
wrote:
Hi folks,
I've attached a patch to the svn trunk that improves the performance
of the serialize/unserialize interface for vector types. The current
implementation: a) invokes the R_XDREncode operation for each element
of the vector type, and b) uses a switch statement to determine the
stream type for each element of the vector type. I've added
R_XDREncodeVector/R_XDRDecodeVector functions that accept N elements
at a time, and I've reorganized the implementation so that the stream
type is not queried once per element.
In the following microbenchmark (below), I've observed performance
improvements of about x2.4. In a real benchmark that is using the
serialization interface to make MPI calls, I see about a 10%
improvement in performance.
Cheers,
--Michael
microbenchmark:
input <- matrix(1:1, 1, 1)
output <- serialize(input, NULL)
for(i in 1:10) { print(system.time(serialize(input, NULL))) }
for(i in 1:10) { print(system.time(unserialize(output))) }
__
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
--
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] Unable to reload Rdoc
This is simply not supported. Lazy-load databases are cached, and you
cannot expect to change them during the R session once they have been used.
Spend the few milliseconds needed to start a new session.
And R CMD Rdconv is a much simpler way to check a changed .Rd file.
On 27/01/2012 09:47, Mark Cowley wrote:
Dear list,
I'm hoping the R guru's can help with an error i've been getting for at least a
year during active package development.
I have a package loaded& spot a documentation bug, so I:
edit the Rd file (or in the roxygen header + roxygenize); then
R CMD BUILD,
R CMD INSTALL
then in the same R session, reload the library& lookup a man page, I always
get this error:
Error in fetch(key) : internal error -3 in R_decompress1
I've tried all ways of reloading the package that i'm aware of:
detach then library
unloadNamespace then library
devtools::install
devtools::reload
all lead to the error.
I see from ?detach:
... So detaching and re-attaching a package may
not refresh some or all components of the package, and is
inadvisable.
You were warned
restarting the R session results in loading the updated man file, but do you have
any ideas how to word around this& continue within the same R session?
cheers,
Mark
# 1) using Hadley's devtools
library(devtools)
library(updateR) # my package under development
install("~/src/R/updateR")
install("~/src/R/updateR")
Installing updateR
* checking for file ‘/Users/marcow/src/R/updateR/DESCRIPTION’ ... OK
* preparing ‘updateR’:
* checking DESCRIPTION meta-information ... OK
* checking for LF line-endings in source and make files
* checking for empty or unneeded directories
* building ‘updateR_1.0.4.tar.gz’
Warning in normalizePath(c(new, .Library.site, .Library), "/") :
path[3]="": No such file or directory
* installing *source* package ‘updateR’ ...
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
* DONE (updateR)
Reloading installed updateR
?get.full.path
Error in fetch(key) : internal error -3 in R_decompress1
2) using detach + library
$ R --vanilla
library(updateR)
# ?list.my.packages
detach(pos=2, unload=TRUE, force=TRUE)
#<>
system("cd ~/src/R&& R CMD BUILD updateR&& R CMD INSTALL updateR")
library("updateR")
?list.my.packages
Error in fetch(key) : internal error -3 in R_decompress1
3) using unloadNamespace
$ R --vanilla
library(updateR)
# ?list.my.packages
unloadNamespace("updateR")
#<>
system("cd ~/src/R&& R CMD BUILD updateR&& R CMD INSTALL updateR")
library("updateR")
?list.my.packages
Error in fetch(key) : internal error -3 in R_decompress1
sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_AU.UTF-8/en_AU.UTF-8/C/C/en_AU.UTF-8/en_AU.UTF-8
attached base packages:
[1] tools stats graphics grDevices datasets utils methods
[8] base
other attached packages:
[1] updateR_1.0.4 codetools_0.2-8 devtools_0.4
loaded via a namespace (and not attached):
[1] RCurl_1.6-7
-
Mark Cowley, PhD
Pancreatic Cancer Program | Peter Wills Bioinformatics Centre
Garvan Institute of Medical Research, Sydney, Australia
-
[[alternative HTML version deleted]]
__
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
[Rd] Numerical instability in new R Windows development version
I have a question concerning the new Windows toolchain for R >= 2.14.2. When trying out my package 'pracma' on the win-builder development version it will stop with the following error message: > f3 <- function(x, y) sqrt((1 - (x^2 + y^2)) * (x^2 + y^2 <= 1)) > dblquad(f3, -1, 1, -1, 1) # 2.094395124 , i.e. 2/3*pi , err = 2e-8 Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2 <= 1)) : NaNs produced Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2 <= 1)) : NaNs produced Error in integrate(function(y) f(x, y), ya, yb, subdivisions = subdivs, : non-finite function value Calls: dblquad ... -> f -> do.call -> mapply -> -> integrate Execution halted ** running examples for arch 'x64' ... ERROR Running examples in 'pracma-Ex.R' failed This probably means that the following expression got negative for some values x, y: (1 - (x^2 + y^2)) * (x^2 + y^2 <= 1) It appears to be an often used trick in numerical analysis. One advantage is that a function using it is immediately vectorized while an expression such as, e.g., "max(0, 1 - (x^2 + y^2))" is not. The example runs fine on Debian Linux and Mac OS X 32-/64-bit architectures. In my understanding the approach is correct and, as said above, often used in numerical applications. Can someone explain to me why this fails for the Windows 64-bit compiler and what I should use instead. Thanks. Hans Werner Borchers ABB Corporate Research __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical instability in new R Windows development version
On 12-01-27 7:23 AM, Hans W Borchers wrote: I have a question concerning the new Windows toolchain for R>= 2.14.2. When trying out my package 'pracma' on the win-builder development version it will stop with the following error message: > f3<- function(x, y) sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) > dblquad(f3, -1, 1, -1, 1) # 2.094395124 , i.e. 2/3*pi , err = 2e-8 Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced Error in integrate(function(y) f(x, y), ya, yb, subdivisions = subdivs, : non-finite function value Calls: dblquad ... -> f -> do.call -> mapply ->-> integrate Execution halted ** running examples for arch 'x64' ... ERROR Running examples in 'pracma-Ex.R' failed This probably means that the following expression got negative for some values x, y: (1 - (x^2 + y^2)) * (x^2 + y^2<= 1) I think you're right, it's a bug, hopefully easy to fix. Here's a simpler version: x <- 0*(-1) sqrt(x) x is a "negative zero", and the sqrt() function incorrectly produces a NaN in the new toolchain. Duncan Murdoch It appears to be an often used trick in numerical analysis. One advantage is that a function using it is immediately vectorized while an expression such as, e.g., "max(0, 1 - (x^2 + y^2))" is not. The example runs fine on Debian Linux and Mac OS X 32-/64-bit architectures. In my understanding the approach is correct and, as said above, often used in numerical applications. Can someone explain to me why this fails for the Windows 64-bit compiler and what I should use instead. Thanks. Hans Werner Borchers ABB Corporate Research __ 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] Numerical instability in new R Windows development version
On Jan 27, 2012, at 13:23 , Hans W Borchers wrote: > (1 - (x^2 + y^2)) * (x^2 + y^2 <= 1) > > It appears to be an often used trick in numerical analysis. One advantage is > that a function using it is immediately vectorized while an expression such > as, e.g., "max(0, 1 - (x^2 + y^2))" is not. However, "pmax(0, 1 - (x^2 + y^2))" is (unless 0-length x,y is an issue). But of course, Duncan is right: It is a bug if you can't take the square root of negative zero. -- 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] Unable to reload Rdoc
On Fri, Jan 27, 2012 at 3:47 AM, Mark Cowley wrote:
> Dear list,
> I'm hoping the R guru's can help with an error i've been getting for at least
> a year during active package development.
>
> I have a package loaded & spot a documentation bug, so I:
> edit the Rd file (or in the roxygen header + roxygenize); then
> R CMD BUILD,
> R CMD INSTALL
> then in the same R session, reload the library & lookup a man page, I always
> get this error:
> Error in fetch(key) : internal error -3 in R_decompress1
>
> I've tried all ways of reloading the package that i'm aware of:
> detach then library
> unloadNamespace then library
> devtools::install
> devtools::reload
>
> all lead to the error.
>
> I see from ?detach:
> ... So detaching and re-attaching a package may
> not refresh some or all components of the package, and is
> inadvisable.
>
> restarting the R session results in loading the updated man file, but do you
> have any ideas how to word around this & continue within the same R session?
>
> cheers,
> Mark
>
> # 1) using Hadley's devtools
>> library(devtools)
>> library(updateR) # my package under development
>> install("~/src/R/updateR")
To avoid this problem, the latest version of devtools has show_rd(),
which allows you to preview an Rd file in R without having to
reinstall the package. This was actually really simple to implement,
and I don't know why I didn't think of it ages ago - it's certainly
made my workflow much smoother.
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ignore user interrupts
On Thu, 26 Jan 2012, Sharpie wrote:
Sharpie wrote
evalWithoutInterrupts <- function(expr, envir = parent.frame())
{
.Call(do_evalWithoutInterrupts, expr, envir)
}
With a C-level implemention:
SEXPR do_evalWithoutInterrupts(SEXP expr, SEXP envir)
{
SEXP result;
BEGIN_SUSPEND_INTERRUPTS{
result = eval(expr, envir);
}END_SUSPEND_INTERRUPTS;
return result;
}
Some more info, and a possible bug:
This approach appears to work if I change `evalWithoutInterrupts` so that it
invokes `substitute` on `expr` before passing to the C code:
evalWithoutInterrupts <- function(expr, envir = parent.frame())
{
.Call(do_evalWithoutInterrupts, substitute(expr), envir)
}
For example, I can do the following (using OS X, R 2.14.1 in Terminal.app):
eval({for(i in 1:1000){log(i)};message("Hello, world!")})
evalWithoutInterrupts({for(i in 1:1000){log(i)};message("Hello,
world!")})
The `eval` call can be interrupted by CTRL-C as normal. However, with the
`evalWithoutInterrupts` call, I can tap on CTRL-C and the loop will still
execute, "Hello, world!" will be printed and then the interrupt will be
registered:
> evalWithoutInterrupts({for(i in 1:1000){log(i)};message("Hello,
world!")})
^C^C^C^C^CHello, world!
>
The only odd thing I came across was when I tried to test this function
using `Sys.sleep` instead of a long loop:
evalWithoutInterrupts(Sys.sleep(3);message("Hello, world!")})
The call can be interrupted immediately by CTRL-C. Some poking in GDB
reveals that the call chain passes from my C function
`evalWithoutInterrupts` to `do_syssleep` an finally to `Rf_onintr` through
`R_checkActivity`:
Breakpoint 1, Rf_onintr () at errors.c:123
123 if (R_interrupts_suspended) {
(gdb) bt
#0 Rf_onintr () at errors.c:123
#1 0x0001001ced41 in R_SelectEx (n=1, readfds=0x10038cdc0,
writefds=0x0, exceptfds=0x0, timeout=0x7fff5fbf8b60, intr=0) at
sys-std.c:127
#2 0x0001001cf109 in R_checkActivityEx (usec=300, ignore_stdin=1,
intr=0) at sys-std.c:329
#3 0x0001001cf14b in R_checkActivity (usec=300, ignore_stdin=1) at
sys-std.c:338
#4 0x0001001d0fbb in do_syssleep (call=0x1025bb200, op=0x10086d0d8,
args=0x1033679b8, rho=0x1033679f0) at sys-std.c:1299
#5 0x0001000c7608 in bcEval (body=0x1025ba878, rho=0x1033679f0,
useCache=TRUE) at eval.c:4445
#6 0x0001000bcb69 in Rf_eval (e=0x1025ba878, rho=0x1033679f0) at
eval.c:401
#7 0x0001000bddd7 in Rf_applyClosure (call=0x103366e38, op=0x1025ba8e8,
arglist=0x103367a60, rho=0x100877ea8, suppliedenv=0x100877ee0) at eval.c:840
#8 0x0001000bd22e in Rf_eval (e=0x103366e38, rho=0x100877ea8) at
eval.c:515
#9 0x0001000bf879 in do_begin (call=0x103366ee0, op=0x10084e6e0,
args=0x103366dc8, rho=0x100877ea8) at eval.c:1422
#10 0x0001000bcf40 in Rf_eval (e=0x103366ee0, rho=0x100877ea8) at
eval.c:471
#11 0x000102fc736d in evalWithoutInterrupts ()
However, at this point the variable `R_interrupts_suspended` is not set to
`TRUE` as I would expect due to the `BEGIN_SUSPEND_INTERRUPTS` block in
`evalWithoutInterrupts`:
(gdb) p R_interrupts_suspended
$1 = FALSE
Bug?
No.
The interrupt managemant we have now is intended for the C level to
make sure interrupts can only occur where they are safe for the C
code, and at this point in sleep they are and so do_syssleep enables
them.
There is a need for interrupt management at the R level but getting it
right is not easy. It isn't just a matter of suspending them, but
suspending and and re-enabling them where they are safe. Some code
that would potentially hang needs to enable them -- typically these
are operations that could signal other sorts of errors, like read
errors, timeouts, etc. and code that needs to ensure cleanup code is
run would need to catch those as well. (Interrupts are catchable as
"interrupt" conditions by the way). There is some literature on this
(in particular an article "Asynchronous Exceptions in Haskell") that I
need to study more before implementing something at the R level.
luke
-Charlie
-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context:
http://r.789695.n4.nabble.com/Ignore-user-interrupts-tp4321252p4331653.html
Sent from the R devel mailing list archive at Nabble.com.
__
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: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo
Re: [Rd] Silently loading and Depends: versus NAMESPACE imports
On 12 January 2012 at 12:12, Hervé Pagès wrote:
| Hi Dirk,
|
| On 01/11/2012 11:42 AM, Dirk Eddelbuettel wrote:
| >
| > R CMD check really hates it when my .onLoad() function contains
| > suppressMessages(library(foo))
|
| Note that you can always fool 'R CMD check' by doing something like:
|
| sillyname <- library
| suppressMessages(sillyname("foo"))
|
| Also isn't suppressPackageStartupMessages() more appropriate?
|
| >
| > However, _and for non-public packages not going to CRAN_ I prefer doing this
| > over using explicit Depends or import statements in the NAMESPACE file as
the
| > latter do not give me an ability to make the loading less verbose. With the
| > R universe of packages being as vast as at is, a simple (non-public) package
| > I have loads about five or six other packages explicitly, each of which
loads
| > even more. The net result is totally intimidating _sixty lines full_ of
| > verbose noise that is meaningful to me as an R programmer, but not for the
| > colleagues expected to use the packages. It looks rather uninviting,
frankly.
| >
| > How do I use imports via NAMESPACE, and yet keep the noise level down to
zero?
|
| If you only need to import foo (i.e. and actually don't need to attach
| it to the search path) then putting foo in Imports and using import
| statements in NAMESPACE will keep the noise level down to zero.
I don't think so.
I have an internal package, call it fooUtils, that (among other things) needs
to figure at startup whether it runs on this or that OS.
So that package fooUtils does
.onLoad <- function(libname, pkgname) {
if (.Platform$OS.type == "windows") {
packageStartupMessage("Running on Windows")
# [... more stuff here ... ]
} else if (.Platform$OS.type == "unix") {
packageStartupMessage("Running on Linux")
# [... more stuff here ... ]
} else {
warning("Platform ", .Platform$OS.type, " not recognised")
drives <- NULL
}
#
}
and contrary to your claim, this is not silent as soon as I do
importFrom(fooUtils, someThing)
the messages above pop up. While I can suppress them for 'normal' loads via
suppressMessages(library(fooUtils))
or
suppressPackageStartupMessages(library(fooUtils))
I cannot suppress them via NAMESPACE imports.
Dirk
| So I guess your question is: how do we suppress package startup messages
| for packages listed in Depends?
|
| Cheers,
| H.
|
| >
| > Dirk
| >
|
|
| --
| 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
--
"Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
dark to read." -- Groucho Marx
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] misfeature: forced file.copy() of a file over itself truncates the file ...
Try this:
fn <- "tmp.dat"
x <- 1:3
dump("x",file=fn)
file.info(fn) ## 9 bytes
file.copy(paste("./",fn,sep=""),fn,overwrite=TRUE)
file.info(fn) ## 0 bytes (!!)
Normally file.copy() checks and disallows overwriting a file with
itself, but it only checks whether character string 'from' is the same
as character string 'to' and not whether the copy refers to the same
file by different names, so it lets this go ahead. It then creates a
new file with the name of 'to' using file.create():
‘file.create’ creates files with the given names if they do not
already exist and truncates them if they do.
This trashes the existing 'from' file (which was not detected).
file.copy() then happily appends the contents of 'from' (which is now
empty) to 'to' ...
I don't know whether there's any simple way to fix this, or whether
it's just a case of "don't do that". It might be worth mentioning in
the documentation:
`file.copy' will normally refuse to copy a file to itself, but in
cases where the same file is referred to by different names (as in
copying "/full/path/to/filename" to "filename" in the current working
directory), it will truncate the file to zero.
Now that I write that it really seems like a 'mis-feature'.
On a Unix system I would probably compare inodes, but I don't know if
there's a good system-independent way to test file identity ...
$ ls -i tmp.dat
114080 tmp.dat
$ ls -i /home/bolker/R/pkgs/r2jags/pkg/tests/tmp.dat
114080 /home/bolker/R/pkgs/r2jags/pkg/tests/tmp.dat
Would normalizePath() work for this ... ?
> normalizePath("tmp.dat")
[1] "/mnt/hgfs/bolker/Documents/R/pkgs/r2jags/pkg/tests/tmp.dat"
sincerely
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical instability in new R Windows development version
On 27/01/2012 13:26, Duncan Murdoch wrote: On 12-01-27 7:23 AM, Hans W Borchers wrote: I have a question concerning the new Windows toolchain for R>= 2.14.2. When trying out my package 'pracma' on the win-builder development version it will stop with the following error message: > f3<- function(x, y) sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) > dblquad(f3, -1, 1, -1, 1) # 2.094395124 , i.e. 2/3*pi , err = 2e-8 Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced Error in integrate(function(y) f(x, y), ya, yb, subdivisions = subdivs, : non-finite function value Calls: dblquad ... -> f -> do.call -> mapply -> -> integrate Execution halted ** running examples for arch 'x64' ... ERROR Running examples in 'pracma-Ex.R' failed This probably means that the following expression got negative for some values x, y: (1 - (x^2 + y^2)) * (x^2 + y^2<= 1) I think you're right, it's a bug, hopefully easy to fix. Here's a simpler version: x <- 0*(-1) sqrt(x) x is a "negative zero", and the sqrt() function incorrectly produces a NaN in the new toolchain. Well, for some definition of 'incorrectly'. It is clearly what the author of that piece of code intended. It would be helpful if people would cite definitive references. Someone is going to have to report this on the bugtracker, and at present I don't have enough evidence to do so: the C99/C11 standards do not seem to mandate a particular value (they do say what happens for values less than zero, but C compilers are allowed to have or not have signed zeroes). (Various Unix-alikes say what they do, usually -0, but that's not evidence that other answers are 'incorrect'.) Duncan Murdoch It appears to be an often used trick in numerical analysis. One advantage is that a function using it is immediately vectorized while an expression such as, e.g., "max(0, 1 - (x^2 + y^2))" is not. The example runs fine on Debian Linux and Mac OS X 32-/64-bit architectures. In my understanding the approach is correct and, as said above, often used in numerical applications. Can someone explain to me why this fails for the Windows 64-bit compiler and what I should use instead. Thanks. Hans Werner Borchers ABB Corporate Research __ 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 -- 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] misfeature: forced file.copy() of a file over itself truncates the file ...
Since the problem can only occur if the 'to' file
exists, a check like
if (normalizePath(from) == normalizePath(to)) {
stop("'from' and 'to' files are the same")
}
(after verifying that 'to', and 'from', exist)
would avoid the problem.
S+ has a function, match.path, that can say if two paths refer to
the same file (on Unixen compare inode and device
numbers, on Windows compare the output of normalizePath),
That avoids automounter/NFS problems like the following.
We have a unix machine has two names, "sea-union" and "seabldlnx3201",
and the /nfs directory contains both names. At the shell (on a
second Linux machine) we can see they refer to the same place:
% pwd
/nfs/sea-union
% ls -id usr /nfs/seabldlnx3201/usr /nfs/sea-union/usr
358337 /nfs/seabldlnx3201/usr/ 358337 /nfs/sea-union/usr/ 358337 usr/
% df usr /nfs/seabldlnx3201/usr /nfs/sea-union/usr
Filesystem 1K-blocks Used Available Use% Mounted on
sea-union:/usr15385888 3526656 11077664 25% /nfs/sea-union/usr
seabldlnx3201:/usr15385888 3526656 11077664 25%
/nfs/seabldlnx3201/usr
sea-union:/usr15385888 3526656 11077664 25% /nfs/sea-union/usr
S+'s match.path also indicates that they are the same
S+> getwd()
[1] "/nfs/sea-union"
S+> match.path( c("usr", "/nfs/seabldlnx3201/usr"), "/nfs/sea-union/usr")
[1] 1 1
(The last indicates that both paths in the first argument match the
path in the second, as match() does for strings.)
But R's normalizePath() would lead you to think that they are different
directories
> getwd()
[1] "/nfs/sea-union"
> normalizePath(c("usr", "/nfs/seabldlnx3201/usr", "/nfs/sea-union/usr"))
[1] "/nfs/sea-union/usr" "/nfs/seabldlnx3201/usr" "/nfs/sea-union/usr"
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
> Behalf Of Ben Bolker
> Sent: Friday, January 27, 2012 9:03 AM
> To: r-devel@r-project.org
> Subject: [Rd] misfeature: forced file.copy() of a file over itself truncates
> the file ...
>
>
> Try this:
>
> fn <- "tmp.dat"
> x <- 1:3
> dump("x",file=fn)
> file.info(fn) ## 9 bytes
> file.copy(paste("./",fn,sep=""),fn,overwrite=TRUE)
> file.info(fn) ## 0 bytes (!!)
>
> Normally file.copy() checks and disallows overwriting a file with
> itself, but it only checks whether character string 'from' is the same
> as character string 'to' and not whether the copy refers to the same
> file by different names, so it lets this go ahead. It then creates a
> new file with the name of 'to' using file.create():
>
> 'file.create' creates files with the given names if they do not
> already exist and truncates them if they do.
>
> This trashes the existing 'from' file (which was not detected).
> file.copy() then happily appends the contents of 'from' (which is now
> empty) to 'to' ...
>
> I don't know whether there's any simple way to fix this, or whether
> it's just a case of "don't do that". It might be worth mentioning in
> the documentation:
>
> `file.copy' will normally refuse to copy a file to itself, but in
> cases where the same file is referred to by different names (as in
> copying "/full/path/to/filename" to "filename" in the current working
> directory), it will truncate the file to zero.
>
> Now that I write that it really seems like a 'mis-feature'.
> On a Unix system I would probably compare inodes, but I don't know if
> there's a good system-independent way to test file identity ...
>
> $ ls -i tmp.dat
> 114080 tmp.dat
> $ ls -i /home/bolker/R/pkgs/r2jags/pkg/tests/tmp.dat
> 114080 /home/bolker/R/pkgs/r2jags/pkg/tests/tmp.dat
>
> Would normalizePath() work for this ... ?
>
> > normalizePath("tmp.dat")
> [1] "/mnt/hgfs/bolker/Documents/R/pkgs/r2jags/pkg/tests/tmp.dat"
>
>sincerely
> Ben Bolker
>
> __
> 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] Numerical instability in new R Windows development version
On 27/01/2012 12:32 PM, Prof Brian Ripley wrote: On 27/01/2012 13:26, Duncan Murdoch wrote: > On 12-01-27 7:23 AM, Hans W Borchers wrote: >> I have a question concerning the new Windows toolchain for R>= 2.14.2. >> When trying out my package 'pracma' on the win-builder development >> version >> it will stop with the following error message: >> >> > f3<- function(x, y) sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) >> > dblquad(f3, -1, 1, -1, 1) # 2.094395124 , i.e. 2/3*pi , err = 2e-8 >> Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced >> Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced >> Error in integrate(function(y) f(x, y), ya, yb, subdivisions = subdivs, : >> non-finite function value >> Calls: dblquad ... >>-> f -> do.call -> mapply ->-> integrate >> Execution halted >> ** running examples for arch 'x64' ... ERROR >> Running examples in 'pracma-Ex.R' failed >> >> This probably means that the following expression got negative for some >> values x, y: >> >> (1 - (x^2 + y^2)) * (x^2 + y^2<= 1) > > I think you're right, it's a bug, hopefully easy to fix. Here's a > simpler version: > > x<- 0*(-1) > sqrt(x) > > x is a "negative zero", and the sqrt() function incorrectly produces a > NaN in the new toolchain. Well, for some definition of 'incorrectly'. It is clearly what the author of that piece of code intended. It would be helpful if people would cite definitive references. Someone is going to have to report this on the bugtracker, and at present I don't have enough evidence to do so: the C99/C11 standards do not seem to mandate a particular value (they do say what happens for values less than zero, but C compilers are allowed to have or not have signed zeroes). (Various Unix-alikes say what they do, usually -0, but that's not evidence that other answers are 'incorrect'.) Section 6.3 of IEEE 754-2008 says Except that squareRoot(−0) shall be −0, every numeric squareRoot result shall have a positive sign. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical instability in new R Windows development version
On 27/01/2012 1:26 PM, Duncan Murdoch wrote: On 27/01/2012 12:32 PM, Prof Brian Ripley wrote: > On 27/01/2012 13:26, Duncan Murdoch wrote: > > On 12-01-27 7:23 AM, Hans W Borchers wrote: > >> I have a question concerning the new Windows toolchain for R>= 2.14.2. > >> When trying out my package 'pracma' on the win-builder development > >> version > >> it will stop with the following error message: > >> > >> > f3<- function(x, y) sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) > >> > dblquad(f3, -1, 1, -1, 1) # 2.094395124 , i.e. 2/3*pi , err = 2e-8 > >> Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced > >> Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced > >> Error in integrate(function(y) f(x, y), ya, yb, subdivisions = subdivs, : > >> non-finite function value > >> Calls: dblquad ... > >> -> f -> do.call -> mapply -> -> integrate > >> Execution halted > >> ** running examples for arch 'x64' ... ERROR > >> Running examples in 'pracma-Ex.R' failed > >> > >> This probably means that the following expression got negative for some > >> values x, y: > >> > >> (1 - (x^2 + y^2)) * (x^2 + y^2<= 1) > > > > I think you're right, it's a bug, hopefully easy to fix. Here's a > > simpler version: > > > > x<- 0*(-1) > > sqrt(x) > > > > x is a "negative zero", and the sqrt() function incorrectly produces a > > NaN in the new toolchain. > > Well, for some definition of 'incorrectly'. It is clearly what the > author of that piece of code intended. > > It would be helpful if people would cite definitive references. Someone > is going to have to report this on the bugtracker, and at present I > don't have enough evidence to do so: the C99/C11 standards do not seem > to mandate a particular value (they do say what happens for values less > than zero, but C compilers are allowed to have or not have signed > zeroes). (Various Unix-alikes say what they do, usually -0, but that's > not evidence that other answers are 'incorrect'.) Section 6.3 of IEEE 754-2008 says Except that squareRoot(−0) shall be −0, every numeric squareRoot result shall have a positive sign. I believe the corresponding ISO standard is ISO/IEC/IEEE 60559:2011, but I don't have a copy, and I don't think my library does. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical instability in new R Windows development version
On 27/01/2012 12:32 PM, Prof Brian Ripley wrote: On 27/01/2012 13:26, Duncan Murdoch wrote: > On 12-01-27 7:23 AM, Hans W Borchers wrote: >> I have a question concerning the new Windows toolchain for R>= 2.14.2. >> When trying out my package 'pracma' on the win-builder development >> version >> it will stop with the following error message: >> >> > f3<- function(x, y) sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) >> > dblquad(f3, -1, 1, -1, 1) # 2.094395124 , i.e. 2/3*pi , err = 2e-8 >> Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced >> Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced >> Error in integrate(function(y) f(x, y), ya, yb, subdivisions = subdivs, : >> non-finite function value >> Calls: dblquad ... >>-> f -> do.call -> mapply ->-> integrate >> Execution halted >> ** running examples for arch 'x64' ... ERROR >> Running examples in 'pracma-Ex.R' failed >> >> This probably means that the following expression got negative for some >> values x, y: >> >> (1 - (x^2 + y^2)) * (x^2 + y^2<= 1) > > I think you're right, it's a bug, hopefully easy to fix. Here's a > simpler version: > > x<- 0*(-1) > sqrt(x) > > x is a "negative zero", and the sqrt() function incorrectly produces a > NaN in the new toolchain. Well, for some definition of 'incorrectly'. It is clearly what the author of that piece of code intended. It would be helpful if people would cite definitive references. Someone is going to have to report this on the bugtracker, and at present I don't have enough evidence to do so: the C99/C11 standards do not seem to mandate a particular value (they do say what happens for values less than zero, but C compilers are allowed to have or not have signed zeroes). (Various Unix-alikes say what they do, usually -0, but that's not evidence that other answers are 'incorrect'.) This page: http://pubs.opengroup.org/onlinepubs/9699919799/functions/sqrt.html also says that the correct answer is -0. I don't know if that has any authority at all... Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Numerical instability in new R Windows development version
On Fri, Jan 27, 2012 at 1:40 PM, Duncan Murdoch wrote: > On 27/01/2012 12:32 PM, Prof Brian Ripley wrote: >> >> On 27/01/2012 13:26, Duncan Murdoch wrote: >> > On 12-01-27 7:23 AM, Hans W Borchers wrote: >> >> I have a question concerning the new Windows toolchain for R>= 2.14.2. >> >> When trying out my package 'pracma' on the win-builder development >> >> version >> >> it will stop with the following error message: >> >> >> >> > f3<- function(x, y) sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) >> >> > dblquad(f3, -1, 1, -1, 1) # 2.094395124 , i.e. 2/3*pi , err = 2e-8 >> >> Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced >> >> Warning in sqrt((1 - (x^2 + y^2)) * (x^2 + y^2<= 1)) : NaNs produced >> >> Error in integrate(function(y) f(x, y), ya, yb, subdivisions = >> >> subdivs, : >> >> non-finite function value >> >> Calls: dblquad ... >> >> -> f -> do.call -> mapply -> -> >> >> integrate >> >> Execution halted >> >> ** running examples for arch 'x64' ... ERROR >> >> Running examples in 'pracma-Ex.R' failed >> >> >> >> This probably means that the following expression got negative for >> >> some >> >> values x, y: >> >> >> >> (1 - (x^2 + y^2)) * (x^2 + y^2<= 1) >> > >> > I think you're right, it's a bug, hopefully easy to fix. Here's a >> > simpler version: >> > >> > x<- 0*(-1) >> > sqrt(x) >> > >> > x is a "negative zero", and the sqrt() function incorrectly produces a >> > NaN in the new toolchain. >> >> Well, for some definition of 'incorrectly'. It is clearly what the >> author of that piece of code intended. >> >> It would be helpful if people would cite definitive references. Someone >> is going to have to report this on the bugtracker, and at present I >> don't have enough evidence to do so: the C99/C11 standards do not seem >> to mandate a particular value (they do say what happens for values less >> than zero, but C compilers are allowed to have or not have signed >> zeroes). (Various Unix-alikes say what they do, usually -0, but that's >> not evidence that other answers are 'incorrect'.) > > > This page: > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/sqrt.html > > also says that the correct answer is -0. I don't know if that has any > authority at all... > > Duncan Murdoch Section 5.4.1 "Arithmetic operations" of "IEEE Standard for Floating- Point Arithmetic", IEEE Std 754-2008 says: "The operation squareRoot(x) computes √ x. It has a positive sign for all operands ≥ 0, except that squareRoot(−0) shall be −0." - Steve __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Ignore user interrupts
On Fri, Jan 27, 2012 at 6:25 AM, wrote:
> On Thu, 26 Jan 2012, Sharpie wrote:
>> The only odd thing I came across was when I tried to test this function
>> using `Sys.sleep` instead of a long loop:
>>
>> evalWithoutInterrupts(Sys.sleep(3);message("Hello, world!")})
>>
>> The call can be interrupted immediately by CTRL-C. Some poking in GDB
>> reveals that the call chain passes from my C function
>> `evalWithoutInterrupts` to `do_syssleep` an finally to `Rf_onintr` through
>> `R_checkActivity`:
...
>> However, at this point the variable `R_interrupts_suspended` is not set to
>> `TRUE` as I would expect due to the `BEGIN_SUSPEND_INTERRUPTS` block in
>> `evalWithoutInterrupts`:
>>
>> (gdb) p R_interrupts_suspended
>> $1 = FALSE
>>
>>
>> Bug?
>
>
> No.
>
> The interrupt managemant we have now is intended for the C level to
> make sure interrupts can only occur where they are safe for the C
> code, and at this point in sleep they are and so do_syssleep enables
> them.
Thanks for the confirmation Luke---I figured Sys.sleep was somehow
explicitly ignoring the suspended state of interrupts. However, it
seems possible that a situation could arise where R needs to sleep
while waiting for some information needed to finish a critical
operation. I agree that this sounds like poorly written code, but it
would be nice to have a "do not disturb" sign that sets up a context
where all code will ignore SIGINTs generated by the user---even if
that code is just napping for a few seconds.
If someone really wants to halt a critical section of code, they
should need a signal like SIGTERM or SIGKILL that expresses the
severity of such an action.
> There is a need for interrupt management at the R level but getting it
> right is not easy. It isn't just a matter of suspending them, but
> suspending and and re-enabling them where they are safe. Some code
> that would potentially hang needs to enable them -- typically these
> are operations that could signal other sorts of errors, like read
> errors, timeouts, etc. and code that needs to ensure cleanup code is
> run would need to catch those as well.
The only thing I am worried about are user-generated interrupts. I
have had a few bug reports that are the result of users just being
unlucky enough to signal an interrupt while a filehash operation was
running. I am pretty confident that these operations either complete
or throw an error, so it is very helpful to delay the processing of
SIGINT for a few microseconds until the filehash ops complete.
> (Interrupts are catchable as "interrupt" conditions by the way).
I tried playing around with `tryCatch` before turning my attention to
BEGIN_SUSPEND_INTERRUPTS and didn't have much success. I could not
find any way to create an interrupt handler that returned control to
the interrupted function call at the point where the interrupt was
signaled. For example, the following catches warnings and ignores
them:
withCallingHandlers(expr, warning = function(w)
invokeRestart("muffleWarning"))
I am looking for a similar restart handler that traps interrupts and
continues on with the original function call as if nothing happened
(or maybe keeps track of the rate at which interrupts are being
signaled and finally breaks out if the user seems insistent).
-Charlie
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .C returned array has odd results
Hi, I'm sure this is a fairly simple problem, but I can't seem to find any
specific information in the documentation as to what is going on. I am
writing a simple nearest neighbor program that takes in a set of of points
on a plane and returns the neighbors of those points, for a fixed number of
neighbors. However, the returned integer array that is allocated in R
seems to occasionally return incorrect results.
I thought this would be because of GC, but I thought this was only for
SEXPs, or at least this is the impression I got from reading the
documentation. So is there some obvious reason why my results seem to get
mangled by this call? I have checked my program through several thousand
loops in C, and always get the same results, so I assume that this is
something I'm doing wrong in R.
Here is the code for my .C call. I could post the C code if someone thinks
it's important, but I'm just changing the values of integer array specified
in R.
r.result <-
.C("evalPoly",
as.double(c.polygonX),
as.double(c.polygonY),
as.double(c.neighborX),
as.double(c.neighborY),
integer(c.numberOfNeighbors*c.height*c.length),
as.integer(c.polygonLength),
as.integer(c.neighborLength),
as.integer(c.numberOfNeighbors),
as.integer(c.length),
as.integer(c.height),
DUP=TRUE
)[[5]]
Cheers,
Jonathan
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ftable.formula
William Dunlap writes: > Put the formula first in the argument list or label > the data argument data= and put the formula after it > if you want to use the formula method for ftable. Ack! So it was a question for R-help after all. Thanks Bill, especially for being so polite about it. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .C returned array has odd results
On 27/01/2012 2:46 PM, Jonathan Lisic wrote:
Hi, I'm sure this is a fairly simple problem, but I can't seem to find any
specific information in the documentation as to what is going on. I am
writing a simple nearest neighbor program that takes in a set of of points
on a plane and returns the neighbors of those points, for a fixed number of
neighbors. However, the returned integer array that is allocated in R
seems to occasionally return incorrect results.
I thought this would be because of GC, but I thought this was only for
SEXPs, or at least this is the impression I got from reading the
documentation. So is there some obvious reason why my results seem to get
mangled by this call? I have checked my program through several thousand
loops in C, and always get the same results, so I assume that this is
something I'm doing wrong in R.
You don't show us what your incorrect results are. The most likely
causes are on the C side, and besides just doing the wrong calculation,
I'd be suspicious of out of bounds writes to arrays. Do you treat any
of the other arguments besides the 5th one as arrays? Are you sure the
length of array passed in is long enough? Do you have local allocations
of arrays, and are they long enough? Do your type declarations in C
match the four double* declarations followed by six int* declarations
implied by your .C call?
Duncan Murdoch
Here is the code for my .C call. I could post the C code if someone thinks
it's important, but I'm just changing the values of integer array specified
in R.
r.result<-
.C("evalPoly",
as.double(c.polygonX),
as.double(c.polygonY),
as.double(c.neighborX),
as.double(c.neighborY),
integer(c.numberOfNeighbors*c.height*c.length),
as.integer(c.polygonLength),
as.integer(c.neighborLength),
as.integer(c.numberOfNeighbors),
as.integer(c.length),
as.integer(c.height),
DUP=TRUE
)[[5]]
Cheers,
Jonathan
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] The following code (using rgamma) hangs
Hi,
I'm seeing something that may be a bug in R's standalone math library,
which is packaged by Debian as r-mathlib. I reported it to the Debian BTS
as http://bugs.debian.org/657573
I'm using Debian squeeze, and the code was tested with r-mathlib 2.11.1-6
(default on stable) and 2.14.1-1 (from testing/unstable).
I summarize this report below. The following code with the R math library
hangs. Note that set_seed is defined as taking two unsigned int arguments,
so 0's are valid arguments. I'm guessing that since 0 is as low as an
unsigned integer can go, it represents some kind of edge case.
#define MATHLIB_STANDALONE
#include
int main(void)
{
set_seed(0, 0);
rgamma(1, 1);
}
If I add the definitions of `get_seed` and `set_seed` from
`src/nmath/standalone/sunif.c` to my code, then the hang disappears.
#define MATHLIB_STANDALONE
#include
/* A version of Marsaglia-MultiCarry */
static unsigned int I1=1234, I2=5678;
void set_seed(unsigned int i1, unsigned int i2)
{
I1 = i1; I2 = i2;
}
void get_seed(unsigned int *i1, unsigned int *i2)
{
*i1 = I1; *i2 = I2;
}
int main(void)
{
set_seed(0, 0);
rgamma(1, 1);
}
I assume sunif.c defines the `get_seed` and `set_seed` for the R
standalone random number generation facilities.
However, I wonder why
a) redefining them in my source file makes the hang go away
and
b) why doesn't redefining `get_seed` and `set_seed` (even with the same
definition) give a linker error, since the function has been defined in
the library already?
Dirk also pointed out (in the bug report) that you get the following
##
int main(void)
{
set_seed(0, 0);
cout << "one normal " << norm_rand() << endl;
}
##
edd@max:/tmp$ g++ -o faheem faheem.cpp -lRmath; ./faheem
one normal -inf
One would expect norm_rand to return finite values, even in edge cases.
If you want me to report this as a bug, let me know. Thanks.
Regards, Faheem
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The following code (using rgamma) hangs
On 28 January 2012 at 02:33, Faheem Mitha wrote:
|
| Hi,
|
| I'm seeing something that may be a bug in R's standalone math library,
| which is packaged by Debian as r-mathlib. I reported it to the Debian BTS
| as http://bugs.debian.org/657573
|
| I'm using Debian squeeze, and the code was tested with r-mathlib 2.11.1-6
| (default on stable) and 2.14.1-1 (from testing/unstable).
|
| I summarize this report below. The following code with the R math library
| hangs. Note that set_seed is defined as taking two unsigned int arguments,
| so 0's are valid arguments. I'm guessing that since 0 is as low as an
| unsigned integer can go, it represents some kind of edge case.
|
|
| #define MATHLIB_STANDALONE
| #include
|
| int main(void)
| {
|set_seed(0, 0);
|rgamma(1, 1);
| }
|
|
| If I add the definitions of `get_seed` and `set_seed` from
| `src/nmath/standalone/sunif.c` to my code, then the hang disappears.
|
|
| #define MATHLIB_STANDALONE
| #include
|
| /* A version of Marsaglia-MultiCarry */
|
| static unsigned int I1=1234, I2=5678;
|
| void set_seed(unsigned int i1, unsigned int i2)
| {
| I1 = i1; I2 = i2;
| }
|
| void get_seed(unsigned int *i1, unsigned int *i2)
| {
| *i1 = I1; *i2 = I2;
| }
|
| int main(void)
| {
|set_seed(0, 0);
|rgamma(1, 1);
| }
|
|
| I assume sunif.c defines the `get_seed` and `set_seed` for the R
| standalone random number generation facilities.
|
| However, I wonder why
|
| a) redefining them in my source file makes the hang go away
|
| and
|
| b) why doesn't redefining `get_seed` and `set_seed` (even with the same
| definition) give a linker error, since the function has been defined in
| the library already?
|
| Dirk also pointed out (in the bug report) that you get the following
|
| ##
| int main(void)
| {
| set_seed(0, 0);
| cout << "one normal " << norm_rand() << endl;
| }
| ##
|
| edd@max:/tmp$ g++ -o faheem faheem.cpp -lRmath; ./faheem
| one normal -inf
Well I actually sent you a complete program of which you showed only an
incomplete part. A better quote would have shown all:
#define MATHLIB_STANDALONE
#include
#include
using std::cout;
using std::endl;
int main(void) {
set_seed(0, 0);
cout << "one normal " << norm_rand() << endl;
}
That does indeed return -Inf on my Ubuntu server. It works with other seed
values as does the rgamma which hangs only for value 0 and 0.
Dirk
| One would expect norm_rand to return finite values, even in edge cases.
|
| If you want me to report this as a bug, let me know. Thanks.
|
| Regards, Faheem
|
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
"Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
dark to read." -- Groucho Marx
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unable to reload Rdoc
Related: To simplify reloading a help page after restarting R, I do
have the following in my ~/.Rprofile:
# Always only the HTML help on the same port
local({
port <- sum(c(1e3,10)*as.double(R.Version()[c("major", "minor")]));
ports <- 10*port + 0:9;
options(help.ports=ports);
});
# Try to start HTML help server
tryCatch({
if (interactive()) {
tools::startDynamicHelp();
}
}, error = function(ex) {
print(ex);
})
That way the URL for the help page remain the same (as long as you
only run one R session) and the internal web server is up and running
(no need for help.start()).
My $.02
/Henrik
On Fri, Jan 27, 2012 at 6:15 AM, Hadley Wickham wrote:
> On Fri, Jan 27, 2012 at 3:47 AM, Mark Cowley wrote:
>> Dear list,
>> I'm hoping the R guru's can help with an error i've been getting for at
>> least a year during active package development.
>>
>> I have a package loaded & spot a documentation bug, so I:
>> edit the Rd file (or in the roxygen header + roxygenize); then
>> R CMD BUILD,
>> R CMD INSTALL
>> then in the same R session, reload the library & lookup a man page, I always
>> get this error:
>> Error in fetch(key) : internal error -3 in R_decompress1
>>
>> I've tried all ways of reloading the package that i'm aware of:
>> detach then library
>> unloadNamespace then library
>> devtools::install
>> devtools::reload
>>
>> all lead to the error.
>>
>> I see from ?detach:
>> ... So detaching and re-attaching a package may
>> not refresh some or all components of the package, and is
>> inadvisable.
>>
>> restarting the R session results in loading the updated man file, but do you
>> have any ideas how to word around this & continue within the same R session?
>>
>> cheers,
>> Mark
>>
>> # 1) using Hadley's devtools
>>> library(devtools)
>>> library(updateR) # my package under development
>>> install("~/src/R/updateR")
>
> To avoid this problem, the latest version of devtools has show_rd(),
> which allows you to preview an Rd file in R without having to
> reinstall the package. This was actually really simple to implement,
> and I don't know why I didn't think of it ages ago - it's certainly
> made my workflow much smoother.
>
> Hadley
>
> --
> Assistant Professor / Dobelman Family Junior Chair
> Department of Statistics / Rice University
> http://had.co.nz/
>
> __
> 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] The following code (using rgamma) hangs
On Fri, 27 Jan 2012, Dirk Eddelbuettel wrote:
| Dirk also pointed out (in the bug report) that you get the following
|
| ##
| int main(void)
| {
| set_seed(0, 0);
| cout << "one normal " << norm_rand() << endl;
| }
| ##
|
| edd@max:/tmp$ g++ -o faheem faheem.cpp -lRmath; ./faheem
| one normal -inf
Well I actually sent you a complete program of which you showed only an
incomplete part. A better quote would have shown all:
#define MATHLIB_STANDALONE
#include
#include
using std::cout;
using std::endl;
int main(void) {
set_seed(0, 0);
cout << "one normal " << norm_rand() << endl;
}
That does indeed return -Inf on my Ubuntu server. It works with other seed
values as does the rgamma which hangs only for value 0 and 0.
Yes, apologies for not including the complete code.
Btw, adding the definitions of `get_seed` and `set_seed` from
| `src/nmath/standalone/sunif.c` fixes the problem here as well.
faheem@orwell[default branch:rev 12]:~/corrmodel/bug$ ./edd one normal
-1.26974
where previously it was giving -inf.
Regards, Faheem
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
