similar to: what is R best for? Evidence please.

Ravi Varadhan and I have been looking at UCMINF to try to identify why it gives occasional (but not reproducible) errors, seemingly on Windows only. There is some suspicion that its use of DBLEPR for finessing the Fortran WRITE() statements may be to blame. While I can find DBLEPR in Venables and Ripley, it doesn't get much mention after about 2000 in the archives, though it is in the R FAQ

Ravi Varadhan and I have been looking at UCMINF to try to identify why it gives occasional (but not reproducible) errors, seemingly on Windows only. There is some suspicion that its use of DBLEPR for finessing the Fortran WRITE() statements may be to blame. While I can find DBLEPR in Venables and Ripley, it doesn't get much mention after about 2000 in the archives, though it is in the R FAQ

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

How about allowing underscore? (I believe WRE is silent on this, and I have not tried submitting a package with underscore in the title.) As I pointed out in my OP, _optim()_ works. And we have the advantage that we can distinguish package from function. The purpose of consistent editing is surely to provide the affordances that save us from needing extra documentation, as per Donald Norman's

I was preparing a fix for a minor glitch in my optimx package and R CMD check gave an error that the title was not in title case. It is A Replacement and Extension of the optim() Function R CMD check suggests the incorrect form A Replacement and Extension of the Optim() Function 'Writing R Extensions' suggests single quotes, i.e., A Replacement and Extension of the 'optim()'

> 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

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

Hi, I think that there something wrong with the 'constrOptim' max/minimization function because she doesn?t send extra arguments to 'optim' call. Fact: When I use optim in a f(x,theta)-like function, everything goes ok. But using constrOptim with the same function leads to error... Proof: Make a small change in the 'Rosenbrock Banana function' (taken from the Examples

Hi, I would like to know how to capture the console output from running an algorithm for further analysis. I can capture this using capture.output() but that yields a character vector. I would like to extract the actual numeric values. Here is an example of what I am trying to do. fr <- function(x) { ## Rosenbrock Banana function on.exit(print(f)) x1 <- x[1] x2 <- x[2]

I have not included the previous postings because they came out very strangely on my mail reader. However, the question concerned the choice of minimizer for the zeroinfl() function, which apparently allows any of the current 6 methods of optim() for this purpose. The original poster wanted to use Newton-Raphson. Newton-Raphson (or just Newton for simplicity) is commonly thought to be the

The R function "optim" fails when a function requires additional arguments, if the option "hessian=T" is specified. I am using R Version 1.0.0 on Windows 98. Here is an example of the Rosenbrock Banana function from the optim help example, with the function and gradient modified to take an additonal argument. Note that the call to optim works fine unless a hessian is

Dear All, Hans Borchers and I have been trying to compute "exact" derivatives in R using the idea of complex-step derivatives that Hans has proposed. This is a really, really cool idea. It gives "exact" derivatives with only a minimal effort (same as that involved in computing first-order forward-difference derivative). Unfortunately, we cannot implement this in R as the

In the documentation for 'optim' it gives the following function: fr <- function(x) { ## Rosenbrock Banana function x1 <- x[1] x2 <- x[2] 100 * (x2 - x1 * x1)^2 + (1 - x1)^2 } optim(c(-1.2,1), fr) When I run this code I get: $par [1] 1.000260 1.000506 I am sure I am missing something but why isn't 1,1 a better answer? If I plug 1,1 in the function it seems

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

Dear all, There appears to be a bug in how constrOptim handles ... arguments that are suppose to be passed to optim, according to the documentation. This means you can't get the hessian to be returned, for example (so this is a real problem, and not just a question of mistaken documentation). Looking at the code, it appears that a call to the user-defined f includes the ..., when the ...

I've been creating some R tools that manipulate objective functions for optimization. In so doing, I create a character string with R code, and then want to have it in my workspace. Currently -- and this works fine -- I write the code out, then use source() to bring it in again. Example: cstr<-"jack<-function(x){\n cat(\"Silly x:\")\n print(x) \n }\n" write(cstr,

For a solution that does not require any change to the original function being optimized, the following one-liner could be used, which converts existing functions to functions that return only the first element: returnFirst <- function(fun) function(...) do.call(fun,list(...))[[1]] Example: fr <- function(x) { ## Rosenbrock Banana function x1 <- x[1] x2 <- x[2] ans

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. However, I have for some time used the parentheses to distinguish functions from packages. optim() is a function, optimx a package. Is this something CRAN should be thinking about? I would argue greater benefit to users than title

Apologies if this is posted twice. The r-help mailing system gave an error (reported to moderator) on first try, but it may have gone through. ---------------------------- Original Message ---------------------------- Subject: Re: R-help Digest, Vol 95, Issue 17 From: "Prof. John C Nash" <nashjc at uottawa.ca> Date: Mon, 17 January, 2011 1:04 pm To: r-help at

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