[R] -ffloat-store

[Prof Brian D Ripley]

On Fri, 10 Nov 2000, Peter Perkins wrote:

> hi -
> 
> in the context of funny problems with optim() -- bug report 671 -- Prof
> Brian Ripley  wrote:
> > I think this is the usual problem with inconsistent internal precision
> > on Linux compilers, so try compiling optim.c with -ffloat-store to make
> > gcc IEEE-compliant.
> 
> this was new to me, but then i am somewhat new to linux and gcc.  a grep
> on the R-1.1.1 source dist'n does not match -ffloat-store. 

No: it would be very system-specific.

>  i've lately
> run into funny "jumps" while using optim(), similar to what was
> described in the original bug report.  according to the gcc info page,
> the "extra precision" (how can that be bad?) is a hardware-specific

It can be bad because algebraically identical calculations can be done in
different ways, and even the same calculation in different ways, and on an
ix86 the answer to them will differ depending if the results gets stored
off the FPU or not.  The IEEE 754 standard is intended to ensure that at
least the second does not happen.  The extra precision is a good thing only
if it is always used!

The context of the report was Linux on ix86, and the L-BFGS-B method in
optim.  So the problem was occurring on linux-i686 but not on Solaris-sparc
or even win32-i686.

> issue.  is there any store of R-knowledge on what hardware is affected
> (i'm running on ppc -- the gcc info page mentions m68k and x86) and
> what, if any, other routines might be affected?

We've seen a few, but we try to pin them down.  There was a pestilential
one inside smooth.spline for a while.  We've seen differences between
different (non-)releases of egcs/gcc too, and the commonly used
egcs-2.91.66 seems the most problematic and the only one where I have seen
problems on Windows.

If you are seeing problems with the L-BFGS-B method in optim(), try the
R-devel version which has some tweaks now, mainly to give earlier and
better diagnoses of such problems.  However, the original problem boiled
down to using numerical derivatives in a very poorly scaled problem (I
think because the scaling had been done the wrong way: up not down or
v.v.), so do take a close look at the scaling.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._