similar to: Byte code compile not helpful in R3.0.2

> 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

On 24.04.2015 22:44, Ben Bolker wrote: > Prof J C Nash (U30A <nashjc <at> uottawa.ca> writes: > >> >> 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. > > [snip] to make Gmane happy ... > >> I have found >> >> A Replacement and Extension of the

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()'

There are now several R geographic user groups, and a few have mailing lists on the R mailing list system. Thanks to Martin M, there's also a pointer to a page I'm maintaining to list/describe the groups. The page is at http://macnash.telfer.uottawa.ca/RUG.html Contact me if you have a listing. I'm prepared to wikify it if there is sufficient interest. John Nash

I noted Duncan's comment that an answer had been provided, and went to the archives to find his earlier comment, which I am fairly sure I saw a day or two ago. However, neither May nor June archives show Duncan in the thread except for the msg below (edited for space). Possibly tech failures are causing misunderstandings. JN On 14-06-02 06:00 AM, r-devel-request at r-project.org wrote: >

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

Are other developers finding R 3.1.3 problematic because vignette building requires pandoc 1.12.3, while Linux Mint 17 / Ubuntu 14.04 have 1.12.2.1? R 3.1.2 seems to work fine. I'd very much like to avoid having to build as large a Linux package as pandoc, which has given me issues outside of R (it leaves out words, sentences or paragraphs when converting Latex to epub in a novel I'm

x1<-c(5.548,4.896,1.964,3.586,3.824,3.111,3.607,3.557,2.989,18.053,3.773,1.253,2.094,2.726,1.758,5.011,2.455,0.913,0.890,2.468,4.168,4.810,34.319,1.531,1.481,2.239,4.204,3.463,1.727) y<-c(2.590,3.770,1.270,1.445,3.290,0.930,1.600,1.250,3.450,1.096,1.745,1.060,0.890,2.755,1.515,4.770,2.220,0.590,0.530,1.910,4.010,1.745,1.965,2.555,0.770,0.720,1.730,2.860,0.760)

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

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

> Date: Tue, 2 Apr 2013 06:59:13 -0500 > From: Paul Johnson <pauljohn32 at gmail.com> > To: qi A <send2aqi at gmail.com> > Cc: R-help <r-help at r-project.org> > Subject: Re: [R] DUD (Does not Use Derivatives) for nonlinear > regression in R? > Message-ID: > <CAErODj_1pK8raHyAme_2Wt5zQZ_HqOhRjQ62bChhkORWbW=o2A at mail.gmail.com> > Content-Type:

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

The following example gives output with a line length of 103 on my system. It is causing a nuisance in creating a vignette. Is there something other than e.g., options(width=60) I need to set? The Sweave FAQ suggests this should work. options(width=60) pastured <- data.frame( time=c(9, 14, 21, 28, 42, 57, 63, 70, 79), yield= c(8.93, 10.8, 18.59, 22.33, 39.35, 56.11, 61.73, 64.62,

I appear to have hit one of the "drop" issues raised in some discussions a couple of years ago by Frank Harrell. They don't seem to have been fixed, and I'm under some pressure to get a quick solution for a forecasting task I'm doing. I have been modelling some retail sales data, and the days just after Thanksgiving (US version!) are important. So I created some dummy

Subject: Non-GPL packages for R Packages that are not licensed in a way that permits re-distribution on CRAN are frequently a source of comment and concern on R-help and other lists. A good example of this problem is the Rdonlp2 package that has caused a lot of annoyance for a number of optimization users in R. They are also an issue for efforts like Dirk Eddelbuettel's cran2deb. There

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

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

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

This message is about a curious difference in timing between two ways of computing the same function. One uses expm, so is expected to be a bit slower, but "a bit" turned out to be a factor of >1000. The code is below. We would be grateful if anyone can point out any egregious bad practice in our code, or enlighten us on why one approach is so much slower than the other. The problem