On Fri, Sep 11, 2009 at 5:00 PM, Duncan Murdoch <murd...@stats.uwo.ca> wrote:
> 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
Thanks for the hint, Duncan. Indeed it was an uninitialized value in
the Fortran code.
/Arne
--
Arne Henningsen
http://www.arne-henningsen.name
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
