similar to: optim() problem

dhabby wrote: Last week I run in to a lot a problems triyng to fit an ARIMA model to a time series. The problem is that the internal process of the arima function call function "optim" to estimate the model parameters, so far so good... but my data presents a problem with the default method "BFGS" of the optim function, the output error looks like this:

That's consistent/not surprising if the problem lies in the numerical gradient calculation step ... On 2019-05-06 10:06 a.m., Ravi Varadhan wrote: > Optim's Nelder-Mead works correctly for this example. > > >> optim(par=10, fn=fn, method="Nelder-Mead") > x=10, ret=100.02 (memory) > x=11, ret=121 (calculate) > x=9, ret=81 (calculate) > x=8, ret=64

It seems that it's an old bug that was found in some other packages, but at that time not optim: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15958 and that Duncan Murdoch posted a patch already last Friday :) Thomas Am 06.05.2019 um 16:40 schrieb Ben Bolker: > That's consistent/not surprising if the problem lies in the numerical > gradient calculation step ... >

After some thought, I decided r-devel was probably the best of the R lists for this item. Do feel free to share, as the purpose is to improve documentation and identify potential issues. John Nash The R Consortium has awarded some modest funding for "histoRicalg", a project to document and transfer knowledge of some older algorithms used by R and by other computational systems. These

Hi Tom, I am not entirely sure what the problem, you haven't been very specific. If you want general linear constraints on your parameters, ie linear combinations of parameters summing to some value, constrOptim may be of help. hth, ingmar Ingmar Visser Developmental Processes Research Group Department of Psychology University of Amsterdam http://users.fmg.uva.nl/ivisser/ -----Original

Recently I reported a small bug in optim's SANN method failing to report that it had exceeded the maximum function evaluation limit in the convergence code. This is a small enough matter that I was reluctant to create a full-blown bug report. Indeed in the optimx package Ravi Varadhan and I have been developing on r-forge (under the OptimizeR project) it was a minimal work around to fix

Dear R-Help List, I am using optim, with method=L-BFGS-B, to maximize a likelihood inside a large simulation exercise. This runs fine for most simulated data sets, but for some reason, about 1 out of 100 times, optim will just hang. Using a dumb approach to the problem (i.e. printing the parameter values each time the function being maximized is evaluated), I tracked down when this happens,

Hi Spencer: See the link below about L-BFGS-B below because I had problems with it a good while back (and I think the link description is the cause but I can't prove it ) so eventually I moved to the Rvmmin(b) package. It's a package but really an algorithm. Rvmmin(b) uses a variable-metric algorithm similar to that of L-BFGS-B but without the problem below. It's not surprisingly a

I have tried to compile the working Fortran-90 routines (see attachment) to interface them with R. The compiler automatically caled by R CMD command line prints a bunch of error messages (as follows). I think I'm better off translating the Fortran implementation into R ... which is what I hoped I could avoid. Maura host705:Desktop mauede$ R CMD SHLIB ford.f90 gfortran -arch i386

I am having trouble with optim. It claims to have converged to a minimum, yet it has in the course of the optimization visited many points which are closer to optimal. I would be grateful for any explanation of this behaviour. I'm trying to estimate the parameters in the model X ~ Binomial(1,p) * NegBin(mu,theta). So I define a log likelihood function, and invoke optim thus: o <- optim

On Mon, Mar 4, 2019 at 5:01 PM J C Nash <profjcnash at gmail.com> wrote: > As the original coder (in mid 1970s) of BFGS, CG and Nelder-Mead in > optim(), I've > been pushing for some time for their deprecation. They aren't "bad", but > we have > better tools, and they are in CRAN packages. Similarly, I believe other > optimization > tools in the core

Have you tried "optimx" package that John Nash and I wrote? The main purpose is to be able to readily compare multiple optimizers on a particular class of problems and see which one seems to do the best. It doesn't include nloptr, but most other optimizers are there. Ravi ________________________________________ From: R-devel <r-devel-bounces at r-project.org> on behalf of

Ben Bolker gives some reasons why Numerical Recipes may be problematic as a starting point for R codes. CUP did a masterful job of marketing, but the license is restrictive as the links he gives points out. In some tests, I've also noted that some of the algorithms are less than stellar e.g, convergence tests in one or two optimization routines. Should we have a wiki item to help people find

Hi, I would also be in favor of a stronger stance on licenses. In industry, where we can really get in big trouble for violating a license, we often maintain internal repositories, or need to be careful about filtering what is used from CRAN. I think that is should really be a requirement the package authors commit to stating what the restrictions are on their packages. Nicholas On 10

I have a function of several variables which I wish to minimise over four variables, two of the upper bounds for which are defined in terms of other variables in the model over which minimisation will take place. I cannot work out how to code this in such a way as to avoid getting an error message when I run the code. If anyone can provide any assistance I will be most grateful. Best Regards

I concur with Avraham that capabilities need to be ensured e.g., in recommended packages. I should have mentioned that. My concern is that the core should be focused on the programming language aspects. The computational math and some of the more intricate data management could better be handled by folk outside the core. JN On 2019-03-04 9:12 a.m., Avraham Adler wrote: > On Mon, Mar 4, 2019

> On 25 Apr 2015, at 13:11 , Prof J C Nash (U30A) <nashjc at uottawa.ca> wrote: > > Hendrik pointed out it was the parentheses that gave the complaint. > Single quotes and no parentheses seem to satisfy R CMD check. Perhaps > that needs to be in the WRE. Well, it is in ?toTitleCase: ...However, unknown technical terms will be capitalized unless they are single

Hi, I have noticed that there is a change in the use of ellipses or . in R versions 2.6.1 and later. In versions 2.5.1 and earlier, the . were always at the end of the argument list, but in 2.6.1 they are placed after the main arguments and before method control arguments. This results in the user having to specify the exact (complete) names of the control arguments, i.e. partial matching is

predict.warn() -- a function to display factor levels in new data for linear model prediction that do not exist in the estimating data. Date: 2005-8-24 From: John C. Nash (with thanks to Uwe Ligges for suggestions) nashjc at uottawa.ca Motivation: In computing predictions from a linear model using factors, it is possible to introduce new factor levels. This was encountered on a practical

>>>>> Duncan Murdoch >>>>> on Sun, 26 Mar 2023 12:41:03 -0400 writes: > On 26/03/2023 11:54 a.m., J C Nash wrote: >> A tangential email discussion with Simon U. has >> highlighted a long-standing matter that some tools in the >> base R distribution are outdated, but that so many >> examples and other tools may use