similar to: fortune candidate

Folks: I thought John Nash's comment below was profound and a possible Fortunes candidate: (Aside: I believe it applies to a great deal of what is discussed on this list, not just stochastic optimization.) Cheers, Bert ... (in the context of stochastic optimization) >... As with many tools in this domain, for effective use they > require more knowledge than many of their users

However, trying this on Linux Mint gave package ?installr? is not available (for R version 3.4.2) Has the package not been updated yet? JN Try the installr package. It was designed for this purpose. On Fri, Nov 10, 2017 at 11:49 AM, Bond, Stephen <Stephen.Bond at cibc.com> wrote: > Is there a utility which will allow me to upgrade my R version and update all packages from the old

Despite my years with R, I didn't know about trace(). Thanks. However, my decades in the minimization and root finding game make me like having a trace that gives some info on the operation, the argument and the current function value. I've usually found glitches are a result of things like >= rather than > in tests etc., and knowing what was done is the quickest way to get there.

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

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

Not convinced Jeff is completely right about this not concerning R, since I've found that the application language (R, perl, etc.) makes a difference in how files are accessed by/to OS. He is certainly correct that OS (and versions) are where the actual reading and writing happens, but sometimes the call to those can be inefficient. (Sorry, I've not got examples specifically for file

This issue does not exist on Linux. My Ubuntu updates both R and all packages. Stephen B -----Original Message----- From: J C Nash [mailto:profjcnash at gmail.com] Sent: Friday, November 10, 2017 1:19 PM To: r-help; RICHARD M. HEIBERGER; Bond, Stephen Subject: Re: [R] update R version in windows However, trying this on Linux Mint gave package ?installr? is not available (for R version

In looking at rootfinding for the histoRicalg project (see gitlab.com/nashjc/histoRicalg), I thought I would check how uniroot() solves some problems. The following short example ff <- function(x){ exp(0.5*x) - 2 } ff(2) ff(1) uniroot(ff, 0, 10) uniroot(ff, c(0, 10), trace=1) uniroot(ff, c(0, 10), trace=TRUE) shows that the trace parameter, as described in the Rd file, does not seem to be

Despite the need to focus on pbeta, I'm still willing to put in some effort. But I find it really helps to have 2-3 others involved, since the questions back and forth keep matters moving forward. Volunteers? Thanks to Martin for detailed comments. JN On 2020-03-26 10:34 a.m., Martin Maechler wrote: >>>>>> J C Nash >>>>>> on Thu, 26 Mar 2020

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 (optim::L-BFGS-B, nlm, nlminb) can and should be moved to packages (there are already 2 versions at least of LBFGS

The cautions people have given about starting values are worth heeding. That nlxb() does well in many cases is useful, but not foolproof. And John Fox has shown that the problem can be tackled very simply too. Best, JN On 2023-08-19 18:42, Paul Bernal wrote: > Thank you so much Dr. Nash, I truly appreciate your kind and valuable contribution. > > Cheers, > Paul > > El El

Caching happens, both within the operating system and within the C standard library. Ostensibly the intent for those caches is to help performance, but you are right that different low-level caching algorithms can be a poor match for specific application level use cases such as copying files or parsing text syntax. However, the OS and even the specific file system drivers (e.g. ext4 on flash disk

Over a week ago (on r-help, my bad!) I raised a question of why the ubuntu install instructions https://cran.r-project.org/bin/linux/ubuntu/README.html instruct users with a xenial-based system to use deb https://cloud.r-project.org/bin/linux/ubuntu xenial-cran40/ Looking at https://cloud.r-project.org/bin/linux/ubuntu/ there is no xenial-cran40 directory. However,

I've been implementing a wrapper to the 2011 Fortran version of L-BFGS-B. In optim(), R uses a C translation of a Fortran version (the version number does not appear to be documented by the original authors). The authors of the original Fortran code have updated it and published the reasons in ACM TOMS due to inefficiencies and a bug. In running the checks on the resulting package (which

Hi there Thanks for your answers. I didn't expect that this would be so complex. Honestly, I don't understand everything you wrote since I'm not an IT specialist. But I read something that reading *.rds files is faster than loading *.Rdata and I wanted to proof that for my system and R version. But thanks anyway for your time. Cheers Raphael > -----Urspr?ngliche Nachricht-----

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

On point 1): The standard approach seems to favor the reference BLAS for reasons other than speed. For example, vecLib, Apple's multi-threaded BLAS library, is not the default choice for macOS binaries due to concerns about 'precision'. See: https://cloud.r-project.org/bin/macosx/RMacOSX-FAQ.html#Whic h-BLAS-is-used-and-how-can-it-be-changed_003f This doesn't appear to be Mac-

I spent more time than I should have debugging a script because I wanted x<-seq(0,100)*0.1 but typed x<-seq(O:100)*0.1 seq(0:100) yields 1 to 101, Clearly my own brain to fingers fumble, but possibly one others may want to avoid it. JN

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