From pro|jcn@@h @end|ng |rom gm@||@com  Thu Jan 31 19:32:31 2019
From: pro|jcn@@h @end|ng |rom gm@||@com (ProfJCNash)
Date: Thu, 31 Jan 2019 13:32:31 -0500
Subject: [Rd] nlminb with constraints failing on some platforms
In-Reply-To: <CAP8zaQB+9NCihJxCC34Ox6xh2u61DLjGCHJi5cv0wV3H58DmSw@mail.gmail.com>
References: <b83bb3a0e9674e198eb53d3682171804@dtu.dk>
 <3cbd19df-544b-aeef-7d30-bbbfe9839e48@gmail.com>
 <CAP8zaQB+9NCihJxCC34Ox6xh2u61DLjGCHJi5cv0wV3H58DmSw@mail.gmail.com>
Message-ID: <f8c1343f-6600-3303-7ad5-c3444bf1c098@gmail.com>

I'm not entirely sure what you are asking. However, optimx is really NOT
meant as a production tool. I intend it as a way to
1) try out a lot of optimizers quickly on a user's problem or problem
class to select a method or methods that suit well;
2) to provide (in the source code of optimr()) an example of how to
call the particular optimizers. They all have a lot of different syntax
elements, which in fact are the biggest headache in building and
extending optimx.

Best, JN

On 2019-01-31 9:26 a.m., Amit Mittal wrote:
> 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?
> 
> 5^th ?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
> <mailto: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 <mailto:R-devel at r-project.org> mailing list
>     > https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>     ______________________________________________
>     R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list
>     https://stat.ethz.ch/mailman/listinfo/r-devel
>



[Rd] nlminb with constraints failing on some platforms
ProfJCNash