similar to: A question on R memory management in .Fortran() calls under Windows

I have the following FORTRAN code converted to a DLL: ! my_xmean.f90 ! ! FUNCTIONS/SUBROUTINES exported from my_function.dll: ! my_function - subroutine ! subroutine my_xmean(X,N,XMEAN) ! Expose subroutine my_function to users of this DLL ! !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'my_xmean_'::my_xmean ! Body of my_function DOUBLE PRECISION X(N) XMEAN=0D0 DO J=1,N

Dear all, I am currently trying to create a package wrapping Fortran90 code, the RRTMG radiative transfer model( http://rtweb.aer.com/rrtm_frame.html). I am doing this on a Linux workstation, with gcc/gfortran, in case this matters. The code heavily relies on F90 features, in particular modules, which seem to clash with R's assumptions for calling compiled code. What I have done: -compiled

Dear all, I found the following on R 2.3.1. for Windows XPpro SP2, tested on 2 PCs AMD 64 3700+, Ati 9700 AMD Athlon 2400+, Matrox G550 Do the following: x <- as.matrix(0); fix(x) pasting a big chunk of data, for instance the one below, into a cell of the editor will crash the RGui. 333333333333333333 333333333333333333333333333 33333333333333333333333333333333333333333333

Dear all, switch() called with just the EXPR argument causes R to hang so that the only way to stop it is to kill R. Reproducible example: > switch(EXPR="a") the internal C subroutine behind switch is do_switch located in R/src/main/builtin.c For convenience I reproduce it below. ***************************************************************************** SEXP attribute_hidden

Dear all, I am puzzled at the behaviour of is.loaded() when a dyn.load() call to a a FORTRAN shared library is included in a file to be sourced. A reproducible example is the following: 1. the attached fortran subroutine try_it.f90 performs a summation of the elements of a REAL*8 vector compile with gfortran try_it.f90 -shared -s -otry_it.dll 2. create a file to be sourced (see the attached

I am writing a function in fortran 95, but the intrinsic function MATMUL is not working properly. Here's an example. SUBROUTINE mymult(x,y,res,m,n) IMPLICIT NONE INTEGER :: m,n REAL :: x, y, res DIMENSION :: x(m,n), y(n,m), res(m,m) res = MATMUL(x,y) END SUBROUTINE mymult R CMD SHLIB mat.f95 In R: dyn.load("mat.so") x <-

Dear all, following the thread http://tolstoy.newcastle.edu.au/R/e2/devel/07/09/4338.html regarding the bug in the partial autocorrelation function for multivariate time series. I have prepared a web page with patches and relevant information. http://www2.stat.unibo.it/giannerini/R/pacf.htm Please do not hesitate to contact me for further clarifications regards Simone --

According to ?parCapply: parRapply and parCapply always return a vector. This appears not to be the case in the following minimal reproducible example: > library(parallel) > nslaves <- 2 > cl <- makeCluster(nslaves) > X <- matrix(2,nrow=3,ncol=4) > X <- rbind(c(1,1,0,1),X) > tv <- parCapply(cl,X,FUN=function(x){ +

Dear all, I encountered a problem when compiling the source of R patched 2.10.0 r50499 (19-11-2009) linked to ACML single threaded (4.2.0 or 4.3.0) OS: openSuSE 11.0 x86-64 make fails when it comes to installing mgcv with the following [snip] ** R ** inst ** preparing package for lazy loading Error in loadNamespace(i[[1L]], c(lib.loc, .libPaths())) : non esiste un pacchetto chiamato

Dear all, I found the following behaviour > rf(5,Inf,Inf) [1] 1 1 1 1 1 but > qf(0.1,Inf,Inf) [1] NaN Warning messages: 1: In qf(0.1, Inf, Inf) : value out of range in 'lgamma' 2: In qf(p, df1, df2, lower.tail, log.p) : NaNs produced incidentally, > pf(1.00000000000001,Inf,Inf) [1] 1 > pf(1.0000000000000001,Inf,Inf) [1] 0.5 Is this the expected behaviour? Thanks

Dear all, I am managing a departmental purchase of an Opteron based workstation/server for scientific computing on which we will be running R. The environment will probably be either Unix/Linux or Solaris and the amount of RAM will be 8-16Gb, depending on the number of processors. My main concerns are the following: 1. How much does R benefit from passing from one processor to two/four

Dear all, it looks like that something is wrong with the /bin/windows/base/rpatched.html page as it seems pointing to the 2.8.1rc version. Also, I do not know if it is relevant but notice the dates of the following files on ftp://ftp.stat.math.ethz.ch/Software/CRAN/bin/windows/base/ R-2.8.1pat-win32.exe 31963 KB 22/12/2008 16.15.00 R-2.8.1rc-win32.exe 31991 KB 25/12/2008 9.30.00 thank

Dear all, there seems to be a problem with displayed legends when a multiple figure environment is used, see the following example: par(mfrow=c(1,2)) curve(dnorm,col=4,from=-4,to=4); legend(-4,0.3,legend="curve",lty=1,col=4) legend(-4,0.2,legend="curve",lty=1,col=4) On my machines the first time the command legend() is issued the legend box stretches over the curve.

minimal reproducible example plot(1,1) identify(1,1) # or locator() now, trying to close the window by clicking on the cross of the upper right corner causes Rgui (and Rterm) to crash. I see the same behaviour on 2 different Windows PC (one with Win 8.1 and one with Win 10). I did not see the problem in linux (see below) WINDOWS ************** > sessionInfo() R version 3.3.0 beta

Dear list, I do not know what would be the 'correct' answer to the following but I think that they should return the same value to avoid potential problems and hard to debug errors. Regards, Simone --------------------------------------- > NCOL(NULL) [1] 1 > NROW(NULL) [1] 0 > sessionInfo() R version 4.3.1 RC (2023-06-08 r84523 ucrt) Platform: x86_64-w64-mingw32/x64 (64-bit)

Dear All, I found the following under R 2.3.0 on WINXP (tested on 2 PCs, I do not have access to Linux from this PC, sorry ... ) > set.seed(10) > x <- ts(rnorm(6),frequency=7) > x Time Series: Start = c(1, 1) End = c(1, 6) Frequency = 7 [1] 0.01874617 -0.18425254 -1.37133055 -0.59916772 0.29454513 0.38979430 > x[24] <- NA > x Time Series: Start = c(1, 1) End = c(1, 6)

Dear all, I think I have found a buglet in plot.ts plot.ts(x=1,type="n") # correct: does not show the plot plot.ts(x=1,y=1,type="n") # not correct: does show the plot I did not investigate the problem in depth but it could be related to the switch xy.labels, in fact plot.ts(x=1,y=1,type="n",xy.labels=TRUE) # does show the plot

If of any help, I can reproduce this (on Windows 7) back to at least R 3.0.3 but it's not there in R 3.0.0. (I have *not* checked with R 3.0.1 and 3.0.2 which I don't have installed). /Henrik On Tue, Apr 5, 2016 at 8:23 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > Thanks, I'll track this down. > > Duncan Murdoch > > > On 05/04/2016 9:35 AM,

Dear all, from the help page of quantile: "x ??? numeric vectors whose sample quantiles are wanted. Missing values are ignored." from the help page of IQR: "x ??? a numeric vector." as a matter of facts it seems that both quantile() and IQR() do not check for the presence of a numeric input. See the following: set.seed(11) x <- rbinom(n=11,size=2,prob=.5) x <-

Hi! Is there any package on CRAN that uses Fortran-90/95? I would like to study it. Thanks, Gregor