Skip to content

-ffloat-store

2 messages · Peter Perkins, Brian Ripley

Original
Peter Perkins
# 
hi -

in the context of funny problems with optim() -- bug report 671 -- Prof
Brian Ripley wrote:
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.  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
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?

along the same lines, is there an official R-stance on the accuracy of
libmoto for ppc?  i remember having heard some vague mention on a ppc
newsgroup about the routines in libmoto being fast but not very
accurate.  at one point, i compared results from R with libmoto to
something else and didn't find anything shocking.

thanks for any info.

- peter
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Brian Ripley
#
On Fri, 10 Nov 2000, Peter Perkins wrote:

            

      
      
      
    

        
No: it would be very system-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.

            

      
      
      
    

        
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.