Kasper Kristensen
2019-Jan-28 08:56 UTC
[Rd] 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=sseReverting 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]]
Martin Maechler
2019-Feb-01 09:00 UTC
[Rd] nlminb with constraints failing on some platforms
>>>>> 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>
Berend Hasselman
2019-Feb-01 14:59 UTC
[Rd] nlminb with constraints failing on some platforms
> 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 >
William Dunlap
2019-Feb-02 17:18 UTC
[Rd] nlminb with constraints failing on some platforms
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 >