R devel - Jan 2019 - nlminb with constraints failing on some platforms

I've noticed unstable behavior of nlminb on some Linux systems. The problem
can be reproduced by compiling R-3.5.2 using gcc-8.2 and running the following
snippet:

f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
xhat <- rep(1, 10)
abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE

The example works perfectly when removing the bounds. However, when bounds are
added the snippet returns 'FALSE'.

An older R version (3.4.4), compiled using the same gcc-8.2, did not have the
problem. Between the two versions R has changed the flags to compile Fortran
sources:

< SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store
---
> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse
Reverting to the old SAFE_FFLAGS 'solves' the problem.
> sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Scientific Linux release 6.4 (Carbon)

Matrix products: default
BLAS/LAPACK:
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so

locale:
[1] C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.5.2



	[[alternative HTML version deleted]]

This is not about the failure on some platforms, which is an important
issue. However, what is below may provide a temporary workaround until
the source of the problem is uncovered.

FWIW, the problem seems fairly straightforward for most optimizers at my
disposal in the R-forge (developmental) version of the optimx package at
https://r-forge.r-project.org/projects/optimizer/

I used the code

## KKristensen19nlminb.R
f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
xhat <- rep(1, 10)
abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
opt
library(optimx)
optx <- opm(rep(0,10), f, lower=-1, upper=3, method="ALL")
summary(optx, order=value)
optxc <- opm(rep(0,10), f, gr="grcentral", lower=-1, upper=3,
method="ALL")
summary(optxc, order=value)
optxn <- opm(rep(0,10), f, gr="grnd", lower=-1, upper=3,
method="ALL")
summary(optxn, order=value)

It should not be too difficult to actually supply the gradient, which
would give speedier and more reliable outcomes.


JN



On 2019-01-28 3:56 a.m., Kasper Kristensen via R-devel
wrote:
> I've noticed unstable behavior of nlminb on some Linux systems. The
problem can be reproduced by compiling R-3.5.2 using gcc-8.2 and running the
following snippet:
> 
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> xhat <- rep(1, 10)
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> 
> The example works perfectly when removing the bounds. However, when bounds
are added the snippet returns 'FALSE'.
> 
> An older R version (3.4.4), compiled using the same gcc-8.2, did not have
the problem. Between the two versions R has changed the flags to compile Fortran
sources:
> 
> < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store
> ---
>> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse
> 
> Reverting to the old SAFE_FFLAGS 'solves' the problem.
> 
>> sessionInfo()
> R version 3.5.2 (2018-12-20)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Scientific Linux release 6.4 (Carbon)
> 
> Matrix products: default
> BLAS/LAPACK:
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so
> 
> locale:
> [1] C
> 
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
> 
> loaded via a namespace (and not attached):
> [1] compiler_3.5.2
> 
> 
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

Prof Nash, Prof Galanos

Is it possible to use a generic code stub in front of packages that use
optimx to improve optimx use or curtail it according to the requirements?


Best Regards

Amit

+91 7899381263











 ________________________________________________________________________

Please request Skype as available

5th Year FPM (Ph.D.) in Finance and Accounting Area

Indian Institute of Management, Lucknow, (U.P.) 226013 India

http://bit.ly/2A2PhD

AEA Job profile : http://bit.ly/AEAamit

FMA 2 page profile : http://bit.ly/FMApdf2p
SSRN top10% downloaded since July 2017: http://ssrn.com/author=2665511
________________________________________________________________________


On Thu, Jan 31, 2019 at 7:22 PM ProfJCNash <profjcnash at gmail.com>
wrote:
> This is not about the failure on some platforms, which is an important
> issue. However, what is below may provide a temporary workaround until
> the source of the problem is uncovered.
>
> FWIW, the problem seems fairly straightforward for most optimizers at my
> disposal in the R-forge (developmental) version of the optimx package at
> https://r-forge.r-project.org/projects/optimizer/
>
> I used the code
>
> ## KKristensen19nlminb.R
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> xhat <- rep(1, 10)
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> opt
> library(optimx)
> optx <- opm(rep(0,10), f, lower=-1, upper=3, method="ALL")
> summary(optx, order=value)
> optxc <- opm(rep(0,10), f, gr="grcentral", lower=-1, upper=3,
method="ALL")
> summary(optxc, order=value)
> optxn <- opm(rep(0,10), f, gr="grnd", lower=-1, upper=3,
method="ALL")
> summary(optxn, order=value)
>
> It should not be too difficult to actually supply the gradient, which
> would give speedier and more reliable outcomes.
>
>
> JN
>
>
>
> On 2019-01-28 3:56 a.m., Kasper Kristensen via R-devel wrote:
> > I've noticed unstable behavior of nlminb on some Linux systems.
The
> problem can be reproduced by compiling R-3.5.2 using gcc-8.2 and running
> the following snippet:
> >
> > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> > xhat <- rep(1, 10)
> > abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> >
> > The example works perfectly when removing the bounds. However, when
> bounds are added the snippet returns 'FALSE'.
> >
> > An older R version (3.4.4), compiled using the same gcc-8.2, did not
> have the problem. Between the two versions R has changed the flags to
> compile Fortran sources:
> >
> > < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store
> > ---
> >> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse
> >
> > Reverting to the old SAFE_FFLAGS 'solves' the problem.
> >
> >> sessionInfo()
> > R version 3.5.2 (2018-12-20)
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > Running under: Scientific Linux release 6.4 (Carbon)
> >
> > Matrix products: default
> > BLAS/LAPACK:
>
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so
> >
> > locale:
> > [1] C
> >
> > attached base packages:
> > [1] stats     graphics  grDevices utils     datasets  methods   base
> >
> > loaded via a namespace (and not attached):
> > [1] compiler_3.5.2
> >
> >
> >
> >       [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
	[[alternative HTML version deleted]]

>>>>> Kasper Kristensen via R-devel 
>>>>>     on Mon, 28 Jan 2019 08:56:39 +0000 writes:
    > I've noticed unstable behavior of nlminb on some Linux
    > systems. The problem can be reproduced by compiling
    > R-3.5.2 using gcc-8.2 and running the following snippet:

    > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
    > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
    > xhat <- rep(1, 10)
    > abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE

    > The example works perfectly when removing the bounds. However, when
bounds are added the snippet returns 'FALSE'.

    > An older R version (3.4.4), compiled using the same gcc-8.2, did not
have the problem. Between the two versions R has changed the flags to compile
Fortran sources:

    > < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store
    > ---
    >> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse

    > Reverting to the old SAFE_FFLAGS 'solves' the problem.

    >> sessionInfo()
    > R version 3.5.2 (2018-12-20)
    > Platform: x86_64-pc-linux-gnu (64-bit)
    > Running under: Scientific Linux release 6.4 (Carbon)

    > Matrix products: default
    > BLAS/LAPACK:
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so

    > locale:
    > [1] C

    > attached base packages:
    > [1] stats     graphics  grDevices utils     datasets  methods   base

    > loaded via a namespace (and not attached):
    > [1] compiler_3.5.2

So you us Intel's MKL library for BLAS/LAPACK ..

I also use gcc 8.2 (on Fedora 28 Linux) and R's own BLAS/LAPACK
and don't see such problems:

The code

f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
str(opt)
xhat <- rep(1, 10)
all.equal(opt$par,         xhat,  tol=0) # good: 5.53 e-7
all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE

gives
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
List of 6
 $ par        : num [1:10] 1 1 1 1 1 ...
 $ objective  : num -41.4
 $ convergence: int 0
 $ iterations : int 66
 $ evaluations: Named int [1:2] 96 830
  ..- attr(*, "names")= chr [1:2] "function"
"gradient"
 $ message    : chr "relative convergence (4)"
> xhat <- rep(1, 10)
> all.equal(opt$par,         xhat,  tol=0) # good: 5.53 e-7
[1] "Mean relative difference: 5.534757e-07"
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
[1] "Mean relative difference: 1.816536e-12"
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
[1] TRUE
>
for me. Maybe others can quickly run the above  7 lines and report ?

Maybe there's something else unusual with your Linux
distribution's libraries?

I'm not an expert on these compiler flags; have you seen what
the R-admin manual
    https://cran.r-project.org/doc/manuals/R-admin.html#Linux
says about them?

Best,
Martin

On 01.02.19 10:00, Martin Maechler wrote:
>> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
>> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
>> str(opt)
> List of 6
>  $ par        : num [1:10] 1 1 1 1 1 ...
>  $ objective  : num -41.4
>  $ convergence: int 0
>  $ iterations : int 66
>  $ evaluations: Named int [1:2] 96 830
>   ..- attr(*, "names")= chr [1:2] "function"
"gradient"
>  $ message    : chr "relative convergence (4)"
>> xhat <- rep(1, 10)
>> all.equal(opt$par,         xhat,  tol=0) # good: 5.53 e-7
> [1] "Mean relative difference: 5.534757e-07"
>> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> [1] "Mean relative difference: 1.816536e-12"
>> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> [1] TRUE
>>
> 
> for me. Maybe others can quickly run the above  7 lines and report ?
Similar but not equal results for me:
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
List of 6
 $ par        : num [1:10] 1 1 1 1 1 ...
 $ objective  : num -41.4
 $ convergence: int 0
 $ iterations : int 66
 $ evaluations: Named int [1:2] 96 830
  ..- attr(*, "names")= chr [1:2] "function"
"gradient"
 $ message    : chr "relative convergence (4)"
> xhat <- rep(1, 10)
> all.equal(opt$par,         xhat,  tol=0) # good: 5.53 e-7
[1] "Mean relative difference: 3.266165e-07"
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
[1] "Mean relative difference: 6.722005e-13"
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
[1] TRUE


Setup:

* Debian Stable with gcc 6.2
* R 3.5.2 from CRAN repository
* OpenBLAS

Greetings
Ralf

-- 
Ralf Stubner
Senior Software Engineer / Trainer

daqana GmbH
Dortustra?e 48
14467 Potsdam

T: +49 331 23 61 93 11
F: +49 331 23 61 93 90
M: +49 162 20 91 196
Mail: ralf.stubner at daqana.com

Sitz: Potsdam
Register: AG Potsdam HRB 27966
Ust.-IdNr.: DE300072622
Gesch?ftsf?hrer: Dr.-Ing. Stefan Knirsch, Prof. Dr. Dr. Karl-Kuno Kunze


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<https://stat.ethz.ch/pipermail/r-devel/attachments/20190201/c3a3aa59/attachment.sig>

> On 1 Feb 2019, at 10:00, Martin Maechler <maechler at
stat.math.ethz.ch> wrote:
> 
> ........
>>> sessionInfo()
>> R version 3.5.2 (2018-12-20)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Scientific Linux release 6.4 (Carbon)
> 
>> Matrix products: default
>> BLAS/LAPACK:
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so
> 
>> locale:
>> [1] C
> 
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
> 
>> loaded via a namespace (and not attached):
>> [1] compiler_3.5.2
> 
> So you us Intel's MKL library for BLAS/LAPACK ..
> 
> I also use gcc 8.2 (on Fedora 28 Linux) and R's own BLAS/LAPACK
> and don't see such problems:
> 
> The code
> 
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
> xhat <- rep(1, 10)
> all.equal(opt$par,         xhat,  tol=0) # good: 5.53 e-7
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> 
> gives
> 
>> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
>> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
>> str(opt)
> List of 6
> $ par        : num [1:10] 1 1 1 1 1 ...
> $ objective  : num -41.4
> $ convergence: int 0
> $ iterations : int 66
> $ evaluations: Named int [1:2] 96 830
>  ..- attr(*, "names")= chr [1:2] "function"
"gradient"
> $ message    : chr "relative convergence (4)"
>> xhat <- rep(1, 10)
>> all.equal(opt$par,         xhat,  tol=0) # good: 5.53 e-7
> [1] "Mean relative difference: 5.534757e-07"
>> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> [1] "Mean relative difference: 1.816536e-12"
>> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> [1] TRUE
>> 
> 
> for me. Maybe others can quickly run the above  7 lines and report ?
> 
Identical result on R 3.5.2 on macOS 10.14.3 with the CRAN version of R.


Berend Hasselman
> Maybe there's something else unusual with your Linux
> distribution's libraries?
> 
> I'm not an expert on these compiler flags; have you seen what
> the R-admin manual
>    https://cran.r-project.org/doc/manuals/R-admin.html#Linux
> says about them?
> 
> Best,
> Martin
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

Hello,

R 3.5.2 on ubuntu 18.04. sessionInfo() at the end.
Works with me, same results, cannot reproduce the error.


f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
str(opt)

xhat <- rep(1, 10)
all.equal(opt$par,         xhat,  tol=0) # good: 5.53 e-7
#[1] "Mean relative difference: 5.534757e-07"
all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
#[1] "Mean relative difference: 1.816536e-12"
abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
#[1] TRUE


Hope this helps,

Rui Barradas


sessionInfo()
R version 3.5.2 (2018-12-20)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.1 LTS

Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1

locale:
  [1] LC_CTYPE=pt_PT.UTF-8       LC_NUMERIC=C
  [3] LC_TIME=pt_PT.UTF-8        LC_COLLATE=pt_PT.UTF-8
  [5] LC_MONETARY=pt_PT.UTF-8    LC_MESSAGES=pt_PT.UTF-8
  [7] LC_PAPER=pt_PT.UTF-8       LC_NAME=C
  [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
  [1] Rcpp_1.0.0       rstudioapi_0.8   bindr_0.1.1      magrittr_1.5
  [5] tidyselect_0.2.5 munsell_0.5.0    colorspace_1.3-2 lattice_0.20-38
  [9] R6_2.3.0         rlang_0.3.0.1    stringr_1.3.1    plyr_1.8.4
[13] dplyr_0.7.8      tools_3.5.2      grid_3.5.2       yaml_2.2.0
[17] assertthat_0.2.0 tibble_1.4.2     crayon_1.3.4     bindrcpp_0.2.2
[21] purrr_0.2.5      reshape2_1.4.3   glue_1.3.0       stringi_1.2.4
[25] compiler_3.5.2   pillar_1.3.1     scales_1.0.0     lubridate_1.7.4
[29] pkgconfig_2.0.2  zoo_1.8-4




?s 09:00 de 01/02/2019, Martin Maechler escreveu:
>>>>>> Kasper Kristensen via R-devel
>>>>>>      on Mon, 28 Jan 2019 08:56:39 +0000 writes:
> 
>      > I've noticed unstable behavior of nlminb on some Linux
>      > systems. The problem can be reproduced by compiling
>      > R-3.5.2 using gcc-8.2 and running the following snippet:
> 
>      > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
>      > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
>      > xhat <- rep(1, 10)
>      > abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> 
>      > The example works perfectly when removing the bounds. However,
when bounds are added the snippet returns 'FALSE'.
> 
>      > An older R version (3.4.4), compiled using the same gcc-8.2, did
not have the problem. Between the two versions R has changed the flags to
compile Fortran sources:
> 
>      > < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store
>      > ---
>      >> SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse
> 
>      > Reverting to the old SAFE_FFLAGS 'solves' the problem.
> 
>      >> sessionInfo()
>      > R version 3.5.2 (2018-12-20)
>      > Platform: x86_64-pc-linux-gnu (64-bit)
>      > Running under: Scientific Linux release 6.4 (Carbon)
> 
>      > Matrix products: default
>      > BLAS/LAPACK:
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so
> 
>      > locale:
>      > [1] C
> 
>      > attached base packages:
>      > [1] stats     graphics  grDevices utils     datasets  methods  
base
> 
>      > loaded via a namespace (and not attached):
>      > [1] compiler_3.5.2
> 
> So you us Intel's MKL library for BLAS/LAPACK ..
> 
> I also use gcc 8.2 (on Fedora 28 Linux) and R's own BLAS/LAPACK
> and don't see such problems:
> 
> The code
> 
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> str(opt)
> xhat <- rep(1, 10)
> all.equal(opt$par,         xhat,  tol=0) # good: 5.53 e-7
> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> 
> gives
> 
>> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
>> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
>> str(opt)
> List of 6
>   $ par        : num [1:10] 1 1 1 1 1 ...
>   $ objective  : num -41.4
>   $ convergence: int 0
>   $ iterations : int 66
>   $ evaluations: Named int [1:2] 96 830
>    ..- attr(*, "names")= chr [1:2] "function"
"gradient"
>   $ message    : chr "relative convergence (4)"
>> xhat <- rep(1, 10)
>> all.equal(opt$par,         xhat,  tol=0) # good: 5.53 e-7
> [1] "Mean relative difference: 5.534757e-07"
>> all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> [1] "Mean relative difference: 1.816536e-12"
>> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> [1] TRUE
>>
> 
> for me. Maybe others can quickly run the above  7 lines and report ?
> 
> Maybe there's something else unusual with your Linux
> distribution's libraries?
> 
> I'm not an expert on these compiler flags; have you seen what
> the R-admin manual
>      https://cran.r-project.org/doc/manuals/R-admin.html#Linux
> says about them?
> 
> Best,
> Martin
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

Microsoft R Open 3.4.2
The enhanced R distribution from Microsoft
Microsoft packages Copyright (C) 2017 Microsoft Corporation

Using the Intel MKL for parallel mathematical computing (using 12 cores).

Default CRAN mirror snapshot taken on 2017-10-15.
See: https://mran.microsoft.com/.
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> xhat <- rep(1, 10)
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
[1] FALSE
> opt$objective - f(xhat)
[1] 3.696533
> str(opt)
List of 6
 $ par        : num [1:10] 0.797 0.303 0.285 0.271 0.258 ...
 $ objective  : num -37.7
 $ convergence: int 1
 $ iterations : int 150
 $ evaluations: Named int [1:2] 155 1611
  ..- attr(*, "names")= chr [1:2] "function"
"gradient"
 $ message    : chr "iteration limit reached without convergence (10)"

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Tue, Jan 29, 2019 at 3:59 AM Kasper Kristensen via R-devel <
r-devel at r-project.org> wrote:
> I've noticed unstable behavior of nlminb on some Linux systems. The
> problem can be reproduced by compiling R-3.5.2 using gcc-8.2 and running
> the following snippet:
>
> f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> xhat <- rep(1, 10)
> abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
>
> The example works perfectly when removing the bounds. However, when bounds
> are added the snippet returns 'FALSE'.
>
> An older R version (3.4.4), compiled using the same gcc-8.2, did not have
> the problem. Between the two versions R has changed the flags to compile
> Fortran sources:
>
> < SAFE_FFLAGS = -O2 -fomit-frame-pointer -ffloat-store
> ---
> > SAFE_FFLAGS = -O2 -fomit-frame-pointer -msse2 -mfpmath=sse
>
> Reverting to the old SAFE_FFLAGS 'solves' the problem.
>
> > sessionInfo()
> R version 3.5.2 (2018-12-20)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Scientific Linux release 6.4 (Carbon)
>
> Matrix products: default
> BLAS/LAPACK:
>
/zdata/groups/nfsopt/intel/2018update3/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64_lin/libmkl_gf_lp64.so
>
> locale:
> [1] C
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.2
>
>
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
	[[alternative HTML version deleted]]

I get the failure message. To be specific:

adcomp.git>R CMD BATCH --quiet test_nlminb.R
adcomp.git>cat test_nlminb.Rout
 > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
 > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
 > xhat <- rep(1, 10)
 > abs( opt$objective - f(xhat) ) < 1e-4? ## Must be TRUE
[1] FALSE

My system is described by:
adcomp.git>uname -a
Linux localhost.localdomain 4.17.7-200.fc28.x86_64 #1 SMP Tue Jul 17 16:28:31
UTC 2018 x86_64 x86_64
x86_64 GNU/Linux

My version of R is described by:
Source?????? : R-3.5.2-2.fc28.src.rpm

I have tried passing in the gradient and turning on the trace and it gives
nearly the exact same
trace with and without the gradient.
Here is the output of a very similar case with the gradient:

 > n??? <- 10
 > f??? <- function(x) {
+?????? result <- 0.0
+?????? for( i in 2 : n ) {
+?????????????? result <- result + log( (x[i] - x[i-1])^2 + 0.01 ) + (x[1] -
1.0)^2
+?????? }
+?????? result
+ }
 > g??? <- function(x) {
+?????? result <- rep(0.0, n)
+?????? for( i in 2 : n ) {
+?????????????? result[1]?? <- result[1] + 2.0 * (x[1] - 1.0)
+?????????????? log_arg???? <- ( x[i] - x[i-1] )^2 + 0.01
+?????????????? log_arg_i?? <- 2.0 * (x[i] - x[i-1])
+?????????????? result[i]?? <- result[i]?? + log_arg_i / log_arg
+?????????????? result[i-1] <- result[i-1] - log_arg_i / log_arg
+?????? }
+?????? result
+ }
 > xstart <- rep(0.0, n)
 > opt??? <- nlminb(
+?????? xstart,
+?????? objective=f ,
+?????? gradient=g,
+?????? lower=-3,
+?????? upper=3,
+?????? control=list(trace=1)
+ )
 ? 0:??? -32.446532:? 0.00000? 0.00000? 0.00000? 0.00000? 0.00000 0.00000?
0.00000? 0.00000?
0.00000? 0.00000
... snip ...
150:??? -37.750217: 0.796764 0.303221 0.285377 0.271175 0.257584 0.248540
0.239230 0.234184 0.229395
0.227872
 > opt$par
 ?[1] 0.7967636 0.3032208 0.2853775 0.2711747 0.2575838 0.2485403 0.2392304
 ?[8] 0.2341841 0.2293946 0.2278722
 > g(opt$par)
 ?[1]? 0.23427575 -0.43398577 -0.67415314 -0.11550223 -0.87486481 0.05194325
 ?[7] -0.83926642 -0.05100054 -0.65128392 -0.30441806
 >