R devel - Nov 2011 - 32 vs 64 bit difference?

I've spent the last few hours baffled by a test suite inconsistency.

The exact same library code gives slightly different answers on the home 
and work machines  - found in my R CMD check run.  I've recopied the entire
directory to make sure it's really identical code. 
  The data set and fit in question has a pretty flat "top" to the
likelihood.
I put print statements in to the "f()" function called by optim, and
the
two parameters and the likelihood track perfectly for 48 iterations, then
start to drift ever so slightly:
< theta= -3.254176 -6.201119 ilik= -16.64806 
> theta= -3.254176 -6.201118 ilik= -16.64806 
And at the end of the iteration:
< theta= -3.207488 -8.583329 ilik= -16.70139 
> theta= -3.207488 -8.583333 ilik= -16.70139 
As you can see, they get to the same max, but with just a slightly
different path.

  The work machine is running 64 bit Unix (CentOS) and the home one 32 bit
Ubuntu.
Could this be enough to cause the difference?  Most of my tests are
based on all.equal, but I also print out 1 or 2 full solutions; perhaps 
I'll have to modify that?

Terry Therneau

On Nov 26, 2011, at 05:20 , Terry Therneau wrote:
> I've spent the last few hours baffled by a test suite inconsistency.
> 
> The exact same library code gives slightly different answers on the home 
> and work machines  - found in my R CMD check run.  I've recopied the
entire
> directory to make sure it's really identical code. 
>  The data set and fit in question has a pretty flat "top" to the
likelihood.
> I put print statements in to the "f()" function called by optim,
and the
> two parameters and the likelihood track perfectly for 48 iterations, then
> start to drift ever so slightly:
> < theta= -3.254176 -6.201119 ilik= -16.64806 
>> theta= -3.254176 -6.201118 ilik= -16.64806 
> 
> And at the end of the iteration:
> < theta= -3.207488 -8.583329 ilik= -16.70139 
>> theta= -3.207488 -8.583333 ilik= -16.70139 
> 
> As you can see, they get to the same max, but with just a slightly
> different path.
> 
>  The work machine is running 64 bit Unix (CentOS) and the home one 32 bit
> Ubuntu.
> Could this be enough to cause the difference?  Most of my tests are
> based on all.equal, but I also print out 1 or 2 full solutions; perhaps 
> I'll have to modify that?
We do see quite a lot of that, yes; even running 32 and 64 bit builds on the
same machine, an sometimes to the extent that an algorithm diverges on one
architecture and diverges on the other (just peek over on R-sig-ME). The
comparisons by "make check" on R itself also give off quite a bit of
"last decimal chatter" when the architecture is switched. For some
reason, OSX builds seem more consistent than Windows and Linux, although I have
only anecdotal evidence of that.

However, the basic point is that compilers don't define the sequence of FPU
operations down to the last detail, an internal extended-precision register may
or may not be used, the order of terms in a sum may be changed, etc. Since 64
bit code has different performance characteristics from 32 bit code (since you
shift more data around for pointers), the FPU instructions may be differently
optimized too.
> 
> Terry Therneau
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com