[Rd] bounds violations, infinite loops in optim/L-BFGS-B (PR#671)
Kurt Hornik
Kurt.Hornik@ci.tuwien.ac.at
Tue, 3 Oct 2000 16:31:21 +0200 (CEST)
>>>>> ben writes:
> On Thu, 28 Sep 2000 ripley@stats.ox.ac.uk wrote:
>> It's a feature, on the TODO list to be added one day.
> A quick hack (if anyone wants to do it) is to change line 975 from
> /* Rprintf("in lbfgsb - %s\n", task);*/
> to
> if (trace) Rprintf("in lbfgsb - %s\n", task);
> however, the debugging output that you get is pretty ugly.
>> > Also, a general question: are both nlm() and optim() going to
>> > be around indefinitely? Should I be using one or the other?
> Well, my question was more whether one was preferred or not ... I did
> see a comment in some NEWS file at some point that a built-in function had
> been switched to optim() and so should converge more often.
> At your suggestion I compiled optim.c (and ../appl/lbfgsb.c for good
> measure) with -ffloat-store. The negative parameter jumps went away,
> but I can still provoke optim() to hang with the right (not uncommon)
> choice of bootstrap values. Adding what I thought were reasonable
> parscale values makes my code hang in different places [i.e. the
> particular values that I give below are no longer a problem], but
> doesn't stop it hanging or even reduce the frequency with which it
> hangs. Perhaps now that I have ffloat-store enabled the values below
> will hang under Solaris as well.
> 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 ...
-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._