bounds violations, infinite loops in optim/L-BFGS-B (PR#671)

Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes:

  Should ffloat-store be enabled in general for compilation on Linux
boxes?

I am not sure it should.  We try to be as defensive about compiler flags
as possible.  (We use -D__NO_MATH_INLINES because it fixes a >>bug<<.)
I'd prefer modifying the code if possible ...

It definitely shouldn't... Basically what it does is to defeat the
"guard digits" that are used in Intel FPUs (internally using 10 bytes
rather than 8 for doubles). While there are some rare cases where this
messes up the "endgame" of numerical algorithms, it increases overall
numerical accuracy. Also, storing all floating-point values off-chip
causes a substantial decrease in performance.

In the case(-s ?) I've seen, a routine was trying too hard to squeeze
the last bit of precision out of a termination criterion.

Optimization is another likely culprit for this kind of trouble, so
perhaps one should try turning it off for this code?

O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel 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-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._