similar to: Error in message printed by lbfgsb

Hi I have a FORTRAN version of the L-BFGS-B algorithm and I was comparing it to the code in the lbfgsb.c file available at R-4.0.0.tar.gz Everithing looks the same, except for those two lines that must be printed by the prn3lb function in case of an error (lines 3559 and 3561 in lbfgsb.c): case -5: Rprintf("l(%d) > u(%d). No feasible solution", k, k); break; case -7:

Hi, I wanted to use R's lbfgsb method for minimization from C. Unfortunately, my toy examples always crashes (segmentation fault). What's wrong with it? double eval(int n, double* par, void *ex) { double result = 0; for (int i=0; i<n; ++i) { result += par[i]*par[i]; } printf("result=%.2f\n", result); return result; } void grad(int n, double *par, double *gr,

Hi, I would like to call R's lbfgsb function from my C/C++ code by including R_ext/Applic.h and linking against libR. Currently, I am allocating memory for x (and the other input arrays for lbfgsb) in my C/C++ code via malloc/new. However, this gives a segmentation fault when executing the program. I tried to allocate x via PROTECT(x = NEW_NUMERIC(n)); x_p = NUMERIC_POINTER(x);. This compiles

Hello, It appears that the file ./appl/lbfgsb.c defines setulb() as a static function, and it is included in optim.c, so setulb() is not exported by the R library. I have some sofware that uses setulb() directly, and I would prefer to avoid having to recompile this sofware to export that function. Is there any way to get access to setulb(), or must I use the lower and upper params in optimix?

Can anyone help me with lbfgsb (function for optimization)? It takes the following parameters: void lbfgsb (int n, int lmm, double *x, double *lower, double *upper, int *nbd, double *Fmin, optimfn fn, optimgr gr, int *fail, void *ex, double factr, double pgtol, int *fncount, int *grcount, int maxit, char *msg, int trace, int nREPORT); What do I put for parameter ex (11th parameter)? I looked at

The R-1.2.1 builds have gone fairly smoothly on most of my UNIX architectures, but there were many warnings reported by the picky SGI compiler that could be eliminated in future releases. Generally, I have found the SGI compilers very helpful in ferreting out portability problems, unused and/or obsolete variables, unexpected datatype coercions, etc., and they compile faster than any other