On 9/11/2009 10:48 AM, Arne Henningsen wrote:
Hi!When I run "R CMD check" on the current development version of my R package "frontier" [1], there is no difference between the output of the test scripts in the /tests/ folder and the saved output files (.Rout.save). However, if I change an R file in the /R/ folder, some calls to the Fortran code (called by ".Fortran()") return different results, although the change of the R file is not related to this, e.g. when I add the commands 'print("abc")' or 'newVariable <- 123' to an R file that even does not call the Fortran code. However, adding empty lines or comments does NOT change the values returned by the Fortran code. Different modifications of the R files lead to different results but the same modification always leads to the same results (hence, the results are perfectly reproducible). Since the Fortran code does a non-linear optimization, (slightly) different results (e.g. depending on starting values) could be expected. However, the values passed to the Fortran code are not affected by the modifications that alter the values returned by the Fortran code and I cannot sea any connection between the modification of the R files and the values returned by the Fortran code. Could this phenomenon be caused by an error in the Fortran code, by a bug in R, or is this a usual behavior that an expert would expect in this situation? Any hints are welcome!
It is likely a bug in the Fortran or in R. Since you see it from very simple, well-tested R code like print() and <-, I would bet pretty heavily on it being in the Fortran.
What it sounds like is that some part of the Fortran code depends on uninitialized values, or values outside the bounds of some array. The local variables take on values depending on what last used that portion of memory, so they are reproducible under identical scripts, but their value depends on more than the function arguments.
I don't know Fortran well enough to know if there's an easy way to diagnose this. Does valgrind work for Fortran? In the old days, it used to be possible to fill the unused portion of the stack with FF bytes: these became NaN values in floating point, and -1 in integers, and would often trigger errors in functions that weren't ready for NaNs or negatives. I don't know how to do that on a modern system, though.
Duncan Murdoch ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
