Bug 14965 - smooth.splines doesn't work with --enable-byte-compiled-packages=no, .Fortran problem?
smooth.splines doesn't work with --enable-byte-compiled-packages=no, .Fortran...
Status: CLOSED FIXED
Product: R
Classification: Unclassified
Component: Language
R 2.15.0 patched
x86_64/x64/amd64 (64-bit) Linux
: P5 major
Assigned To: R-core
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-28 18:50 UTC by Radford Neal
Modified: 2012-07-28 02:21 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Radford Neal 2012-06-28 18:50:32 UTC
When R-2.15.1 is built with --enable-byte-compiled-packages=no, it fails the tests on the "stats" package.  The tail of tests/Examples/stats-Ex.Rout.fail is as follows:

> ### Name: smooth.spline
> ### Title: Fit a Smoothing Spline
> ### Aliases: smooth.spline
> ### Keywords: smooth
> 
> ### ** Examples
> 
> require(graphics)
> 
> attach(cars)
> plot(speed, dist, main = "data(cars)  &  smoothing splines")
> cars.spl <- smooth.spline(speed, dist)
Error in smooth.spline(speed, dist) : smoothing parameter value too small
Execution halted

This happens with Intel 64 bit and 32 bit builds, on Ubuntu 12.04, with gcc 4.6.3.

The problem can be reproduced in isolation as follows, immediately after starting R with no workspace loaded:

Type 'q()' to quit R.

> attach(cars)
> cars.spl <- smooth.spline(speed, dist)
> cars.spl <- smooth.spline(speed, dist)
Error in smooth.spline(speed, dist) : smoothing parameter value too small
> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
[1] C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

Notice that smooth.spline(speed,dist) works the first time, then fails the second time.

It seems likely that this bug has to do with .Fortran, since it was changed extensively in 2.15.1.  The bug doesn't occur in 2.15.0.

I suggest that releases be tested with --enable-byte-compiled-packages=no before release.  This problem found that way is probably symptomatic of a bug that will occur in many other contexts.

By the way, page 10 of R-admin incorrectly says that byte code compilation of packages is disabled with --disable-byte-compilation, which is actually not a recognized option.  Also, help(.Fortran) says "For other atomic vectors, the argument is copied before calling the compiled code if it is not otherwise used in the calling code (such as 'output' in the example above).", but it seems "not copied" is what was meant.
Comment 1 Brian Ripley 2012-07-27 22:51:57 UTC
There's a lot of speculation here.

The reason was actually quite prosaic: the code contained

    ## This uses DUP = FALSE which is dangerous since it does change
		    isetup = 0L,
and the C code changed isetup to 1L, but byte-compilation used the compiled variable which was not changed.

That code should never have been used with DUP=FALSE.

The changes to Fortran were tested over all of CRAN for example, with and without byte-compilation.
Comment 2 Brian Ripley 2012-07-27 23:33:54 UTC
And the precise change in 2.15.1 that caused the problem was to replace as.integer(0) by 0L.

Perfectly reasonable when the C code was not documented to change that argument.
Comment 3 Radford Neal 2012-07-28 02:21:50 UTC
(In reply to comment #1)
> There's a lot of speculation here.
> 
> The reason was actually quite prosaic: the code contained
> 
>     ## This uses DUP = FALSE which is dangerous since it does change
>             isetup = 0L,
> and the C code changed isetup to 1L, but byte-compilation used the compiled
> variable which was not changed.
> 
> That code should never have been used with DUP=FALSE.
> 
> The changes to Fortran were tested over all of CRAN for example, with and
> without byte-compilation.

Well, my speculation as to the cause was wrong, but I don't think that shows that my advise to test with --enable-byte-compiled-packages=no before issuing a new release was wrong.