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

[Kurt Hornik]

>>>>> 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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._