Re: [Rd] Incompatible change in R-devel
On 21 March 2017 at 17:18, Prof Brian Ripley wrote:
| On 21/03/2017 16:38, Dirk Eddelbuettel wrote:
| > On 21 March 2017 at 07:29, Prof Brian Ripley wrote:
| > | As of today's commit r72375 all packages with native-routine
| > | registration of C or Fortran routines need to be reinstalled in R-devel
| > | (and that include some of the recommended packages in R itself which
| > | will not be reinstalled via make dependencies, so we advise a clean
| > | rebuild of R).
| >
| > I am confused by this.
| >
| > So in order to test this, I just triggered rebuild of the smaller drd
("daily
| > r-devel") and r-devel Docker images for R.
| >
| > Using drd, I used R 3.3.3 to install digest and anytime (also installing
Rcpp
| > and BH). I then launch the R-devel build freshly created, and reported as
| >
| > root@b00daf469882:/# RD --version
| > R Under development (unstable) (2017-03-21 r72380) -- "Unsuffered
Consequences"
| >
| > yet both digest and anytime loaded fine by R-devel. Despite the fact that
| > they were installed by R 3.3.3.
|
| None register C/Fortran routines for .C or .Fortran.
Thanks for the prompt follow-up. Between your email and corresponding entry
in NEWS tagged over at the 'daily r-devel changes' RSS feed, I was also
thinking this might be limited to .C and .Fortran, but _not_ the .Call so
much more common in my world.
| My belief is that packages which register more than one .C or more than
| one .Fortran native routine are affected, but that may not be exhaustive
| (and might depend on the compiler).
Ok, thanks for the clarification.
| > As I understand your email, that should not have worked. So I must be
| > missing something -- can you help set me straight?
|
| All packages should load ... the issue is finding (all of the)
| registered symbols. Here's an example of what can go wrong, x86_64 Linux;
|
| > library(mgcv, lib = "/usr/local/lib64/R/library") # R 3.3.3
| Loading required package: nlme
| This is mgcv 1.8-17. For overview type 'help("mgcv-package")'.
| > mgcv:::in.out
| ...
| um <- .C(C_in_out, bx = as.double(bnd[, 1]), by = as.double(bnd[,
| ...
| > mgcv:::C_in_out
| Error in get(name, envir = asNamespace(pkg), inherits = FALSE) :
|object 'C_in_out' not found
|
| (the last message being found in testing a package which called mgcv).
Thanks also for the illustration.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error "Warning in read_symbols_from_dll(so, rarch): this requires 'objdump.exe' to be on the PATH
On 21/03/2017 17:12, Uwe Ligges wrote: On 19.03.2017 23:50, Christophe Genolini wrote: Hi all, I try to compile my package kml and I get the message [That will not be 'compiling': it may be from R CMD check, e.g. from wuth --as-cran in R-devel.] Warning in read_symbols_from_dll(so,rarch): this requires 'objdump.exe' to be on the PATH I check 'Writing R Extensions' but I did not find any reference to this error. Does someone know how to fix that? Yes: Put objdump.exe on the PATH, that executable is part of gcc and in its bin directoy. Not quite: it is part of GNU Bintools, hence bundled with gcc in Rtools. So is 'nm', which may appear in a similar message (and on Windows means 'nm.exe'). -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Incompatible change in R-devel
On 21/03/2017 16:38, Dirk Eddelbuettel wrote:
Hi Brian,
On 21 March 2017 at 07:29, Prof Brian Ripley wrote:
| As of today's commit r72375 all packages with native-routine
| registration of C or Fortran routines need to be reinstalled in R-devel
| (and that include some of the recommended packages in R itself which
| will not be reinstalled via make dependencies, so we advise a clean
| rebuild of R).
I am confused by this.
So in order to test this, I just triggered rebuild of the smaller drd ("daily
r-devel") and r-devel Docker images for R.
Using drd, I used R 3.3.3 to install digest and anytime (also installing Rcpp
and BH). I then launch the R-devel build freshly created, and reported as
root@b00daf469882:/# RD --version
R Under development (unstable) (2017-03-21 r72380) -- "Unsuffered Consequences"
yet both digest and anytime loaded fine by R-devel. Despite the fact that
they were installed by R 3.3.3.
None register C/Fortran routines for .C or .Fortran.
My belief is that packages which register more than one .C or more than
one .Fortran native routine are affected, but that may not be exhaustive
(and might depend on the compiler).
As I understand your email, that should not have worked. So I must be
missing something -- can you help set me straight?
All packages should load ... the issue is finding (all of the)
registered symbols. Here's an example of what can go wrong, x86_64 Linux;
> library(mgcv, lib = "/usr/local/lib64/R/library") # R 3.3.3
Loading required package: nlme
This is mgcv 1.8-17. For overview type 'help("mgcv-package")'.
> mgcv:::in.out
...
um <- .C(C_in_out, bx = as.double(bnd[, 1]), by = as.double(bnd[,
...
> mgcv:::C_in_out
Error in get(name, envir = asNamespace(pkg), inherits = FALSE) :
object 'C_in_out' not found
(the last message being found in testing a package which called mgcv).
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error "Warning in read_symbols_from_dll(so, rarch): this requires 'objdump.exe' to be on the PATH
On 19.03.2017 23:50, Christophe Genolini wrote: Hi all, I try to compile my package kml and I get the message Warning in read_symbols_from_dll(so,rarch): this requires 'objdump.exe' to be on the PATH I check 'Writing R Extensions' but I did not find any reference to this error. Does someone know how to fix that? Yes: Put objdump.exe on the PATH, that executable is part of gcc and in its bin directoy. Best, Uwe Ligges Thank you very much for your help. Christophe __ 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] Hyperbolic tangent different results on Windows and Mac
On 21.03.2017 10:54, Martin Maechler wrote:
Rodrigo Zepeda
on Fri, 17 Mar 2017 12:56:06 -0600 writes:
> Dear all,
> We seem to have found a "strange" behaviour in the hyperbolic tangent
> function tanh on Windows.
> When running tanh(356 + 0i) the Windows result is NaN + 0.i while on Mac
> the result is 1 + 0i. It doesn't seem to be a floating point error because
> on Mac it is possible to run arbitrarily large numbers (say tanh(
>
99677873648767519238192348124812341234182374817239847812738481234871823+0i)
> ) and still get 1 + 0i as result. This seems to be related to the
imaginary
> part as tanh(356) returns 1 in both Windows and Mac.
> We have obtained those results in:
> 1) Mac with El Capitan v 10.11.6 *processor: 2.7 GHz Intel Core i5*
> - 2) Mac with Sierra v 10.12.3 *processor: 3.2 GHz Intel Core i5*
> - 3) Windows 10 Home v 1607 *processor: Intel Core m3-SY30 CPU@ 0.90 GHz
> 1.51 GHz*
> - 4) Windows 7 Home Premium Service Pack 1 *processor: Intel Core i5-2410M
> CPU @2.30 GHz 2.30GHz.*
(The hardware should not matter).
Yes, there is a bug here on Windows only, (several Linux
versions work correctly too).
> In all cases we are using R version 3.3.3 (64 bits)
> - *Does anybody have a clue on why is this happening?*
> PS: We have previously posted this issue in Stack Overflow (
>
http://stackoverflow.com/questions/42847414/hyperbolic-tangent-in-r-throws-nan-in-windows-but-not-in-mac).
> A comment suggests it is related to a glibc bug.
Yes, that would have been my guess too... as indeed, R on
Windows which should work for quite old versions of Windows has
been using a relatively old (gcc / libc) toolchain.
The upcoming version of R 3.4.0 uses a considerably newer
toolchain *BUT* I've just checked the latest "R-devel" binary
and the bug is still present there.
Here's a slight extension of the answer I wrote to the
above SO question here: http://stackoverflow.com/a/42923289/161921
... Windows uses somewhat old C libraries, and here it is the
"mathlib" part of glibc.
More specifically, according to the CRAN download page for R-devel for Windows
https://cran.r-project.org/bin/windows/base/rdevel.html ,
the R 3.3.z series uses the gcc 4.6.3 (March 2012) toolchain, whereas
"R-devel", the upcoming (not yet released!) R 3.4.z series uses
the gcc 4.9.3 (June 2015) toolchain.
Actually the R-3.3.z series already uses gcc-4.9.3.
Best,
Uwe Ligges
According to Ben Bolker's comment on SO, the bug in glibc should have
been fixed in 2012 -- and so the change from 4.6.3 to 4.9.3
should have helped,
**however* I've just checked (installed the R-devel binary from CRAN on our
Windows server virtual machine) and I see that the problem is still present
there: In yesterday's version of R-devel, tanh(500+0i) still returns NaN+0i.
I now think a better solution would be to use R's internal
substitute (in R's src/main/complex.c): There, we have
#ifndef HAVE_CTANH
#define ctanh R_ctanh
static double complex ctanh(double complex z)
{
return -I * ctan(z * I); /* A&S 4.5.9 */
}
#endif
and we should use it (by "#undef HAVE_CTAN" (or better by a
configure check, using ctanh("500 + 0i"),
as I see that on Windows,
R> -1i * tan((500+0i)*1i)
gives
[1] 1+0i
as it should for tanh(500+0i) --- but does not on Windows.
Martin Maechler
ETH Zurich and R Core
__
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] Incompatible change in R-devel
Hi Brian,
On 21 March 2017 at 07:29, Prof Brian Ripley wrote:
| As of today's commit r72375 all packages with native-routine
| registration of C or Fortran routines need to be reinstalled in R-devel
| (and that include some of the recommended packages in R itself which
| will not be reinstalled via make dependencies, so we advise a clean
| rebuild of R).
I am confused by this.
So in order to test this, I just triggered rebuild of the smaller drd ("daily
r-devel") and r-devel Docker images for R.
Using drd, I used R 3.3.3 to install digest and anytime (also installing Rcpp
and BH). I then launch the R-devel build freshly created, and reported as
root@b00daf469882:/# RD --version
R Under development (unstable) (2017-03-21 r72380) -- "Unsuffered Consequences"
yet both digest and anytime loaded fine by R-devel. Despite the fact that
they were installed by R 3.3.3.
As I understand your email, that should not have worked. So I must be
missing something -- can you help set me straight?
Thanks, Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hyperbolic tangent different results on Windows and Mac
> Rodrigo Zepeda
> on Fri, 17 Mar 2017 12:56:06 -0600 writes:
> Dear all,
> We seem to have found a "strange" behaviour in the hyperbolic tangent
> function tanh on Windows.
> When running tanh(356 + 0i) the Windows result is NaN + 0.i while on Mac
> the result is 1 + 0i. It doesn't seem to be a floating point error because
> on Mac it is possible to run arbitrarily large numbers (say tanh(
>
99677873648767519238192348124812341234182374817239847812738481234871823+0i)
> ) and still get 1 + 0i as result. This seems to be related to the
imaginary
> part as tanh(356) returns 1 in both Windows and Mac.
> We have obtained those results in:
> 1) Mac with El Capitan v 10.11.6 *processor: 2.7 GHz Intel Core i5*
> - 2) Mac with Sierra v 10.12.3 *processor: 3.2 GHz Intel Core i5*
> - 3) Windows 10 Home v 1607 *processor: Intel Core m3-SY30 CPU@ 0.90 GHz
> 1.51 GHz*
> - 4) Windows 7 Home Premium Service Pack 1 *processor: Intel Core i5-2410M
> CPU @2.30 GHz 2.30GHz.*
(The hardware should not matter).
Yes, there is a bug here on Windows only, (several Linux
versions work correctly too).
> In all cases we are using R version 3.3.3 (64 bits)
> - *Does anybody have a clue on why is this happening?*
> PS: We have previously posted this issue in Stack Overflow (
>
http://stackoverflow.com/questions/42847414/hyperbolic-tangent-in-r-throws-nan-in-windows-but-not-in-mac).
> A comment suggests it is related to a glibc bug.
Yes, that would have been my guess too... as indeed, R on
Windows which should work for quite old versions of Windows has
been using a relatively old (gcc / libc) toolchain.
The upcoming version of R 3.4.0 uses a considerably newer
toolchain *BUT* I've just checked the latest "R-devel" binary
and the bug is still present there.
Here's a slight extension of the answer I wrote to the
above SO question here: http://stackoverflow.com/a/42923289/161921
... Windows uses somewhat old C libraries, and here it is the
"mathlib" part of glibc.
More specifically, according to the CRAN download page for R-devel for Windows
https://cran.r-project.org/bin/windows/base/rdevel.html ,
the R 3.3.z series uses the gcc 4.6.3 (March 2012) toolchain, whereas
"R-devel", the upcoming (not yet released!) R 3.4.z series uses
the gcc 4.9.3 (June 2015) toolchain.
According to Ben Bolker's comment on SO, the bug in glibc should have
been fixed in 2012 -- and so the change from 4.6.3 to 4.9.3
should have helped,
**however* I've just checked (installed the R-devel binary from CRAN on our
Windows server virtual machine) and I see that the problem is still present
there: In yesterday's version of R-devel, tanh(500+0i) still returns NaN+0i.
I now think a better solution would be to use R's internal
substitute (in R's src/main/complex.c): There, we have
#ifndef HAVE_CTANH
#define ctanh R_ctanh
static double complex ctanh(double complex z)
{
return -I * ctan(z * I); /* A&S 4.5.9 */
}
#endif
and we should use it (by "#undef HAVE_CTAN" (or better by a
configure check, using ctanh("500 + 0i"),
as I see that on Windows,
R> -1i * tan((500+0i)*1i)
gives
[1] 1+0i
as it should for tanh(500+0i) --- but does not on Windows.
Martin Maechler
ETH Zurich and R Core
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] outer not applying a constant function
> William Dunlap > on Mon, 20 Mar 2017 10:20:11 -0700 writes: >> Or is this a bad idea? > I don't like the proposal. I have seen code like the following (in > fact, I have written such code, where I had forgotten a function was > not vectorized) where the error would have been discovered much later > if outer() didn't catch it. >> outer(1:3, 11:13, sum) > Error in outer(1:3, 11:13, sum) : >dims [product 9] do not match the length of object [1] > Bill Dunlap > TIBCO Software > wdunlap tibco.com You are right, thank you! Such a "convenience change" would not be a good idea. Martin Maechler ETH Zurich > On Mon, Mar 20, 2017 at 6:36 AM, Martin Maechler > wrote: >>> Gebhardt, Albrecht >>> on Sun, 19 Mar 2017 09:14:56 + writes: >> >> > Hi, >> > the function outer can not apply a constant function as in the last line of the following example: >> >> >> xg <- 1:4 >> >> yg <- 1:4 >> >> fxyg <- outer(xg, yg, function(x,y) x*y) >> >> fconstg <- outer(xg, yg, function(x,y) 1.0) >> > Error in outer(xg, yg, function(x, y) 1) : >> > dims [product 16] do not match the length of object [1] >> >> > Of course there are simpler ways to construct a constant matrix, that is not my point. >> >> > It happens for me in the context of generating matrices of partial derivatives, and if on of these partial derivatives happens to be constant it fails. >> >> > So e.g this works: >> >> > library(Deriv) >> > f <- function(x,y) (x-1.5)*(y-1)*(x-1.8)+(y-1.9)^2*(x-1.1)^3 >> > fx <- Deriv(f,"x") >> > fy <- Deriv(f,"y") >> > fxy <- Deriv(Deriv(f,"y"),"x") >> > fxx <- Deriv(Deriv(f,"x"),"x") >> > fyy <- Deriv(Deriv(f,"y"),"y") >> >> > fg <- outer(xg,yg,f) >> > fxg <- outer(xg,yg,fx) >> > fyg <- outer(xg,yg,fy) >> > fxyg <- outer(xg,yg,fxy) >> > fxxg <- outer(xg,yg,fxx) >> > fyyg <- outer(xg,yg,fyy) >> >> > And with >> >> > f <- function(x,y) x+y >> >> > it stops working. Of course I can manually fix this for that special case, but thats not my point. I simply thought "outer" should be able to handle constant functions. >> >> ?outer clearly states that FUN needs to be vectorized >> >> but function(x,y) 1is not. >> >> It is easy to solve by wrapping the function in Vectorize(.): >> >>> x <- 1:3; y <- 1:4 >> >>> outer(x,y, function(x,y) 1) >> Error in dim(robj) <- c(dX, dY) : >> dims [product 12] do not match the length of object [1] >> >>> outer(x,y, Vectorize(function(x,y) 1)) >> [,1] [,2] [,3] [,4] >> [1,]1111 >> [2,]1111 >> [3,]1111 >> >> >> >> So, your "should" above must be read in the sense >> >> "It really would be convenient here and >> correspond to other "recycling" behavior of R" >> >> and I agree with that, having experienced the same inconvenience >> as you several times in the past. >> >> outer() being a nice R-level function (i.e., no C speed up) >> makes it easy to improve: >> >> Adding something like the line >> >> if(length(robj) == 1L) robj <- rep.int(robj, dX*dY) >> >> beforedim(robj) <- c(dX, dY) [which gave the error] >> >> would solve the issue and not cost much (in the cases it is unneeded). >> >> Or is this a bad idea? >> >> __ >> 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] Incompatible change in R-devel
As of today's commit r72375 all packages with native-routine registration of C or Fortran routines need to be reinstalled in R-devel (and that include some of the recommended packages in R itself which will not be reinstalled via make dependencies, so we advise a clean rebuild of R). We try to avoid such things, but now is a least bad time (before binary packages for pre-3.4.0 are built in earnest, although CRAN Windows ones have been available for a while and will be rebuilt now). Packages aster2 used undocumented/defunct fields and is overdue for update: AFIAWK all other CRAN/BioC packages can be reinstalled. -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
