[R-pkg-devel] query about package design
I have a general question about appropriate design for a fairly complicated package, as I am redesigning and rebuilding the optimx package. It will get a new name as it appears that the calls will change in order to accommodate new functionality. I plan to make it fairly easy to add new optimization (function minimization) tools. The query is whether to use an environment to hold all the common objects (functions, scaled functions, gradients, scaled gradients, hessians, scaled hessians, parameters, scaled parameters, program controls, algorithm tuning parameters, constraints, fixed parametes, some function value history, etc.) The alternative is a set of very long calls, especially when the function needing a quantity may be a couple of layers below the routine that creates or sets the values. The negative side is that the functions are not portable outside the package, so would not be exported. Before I dig into the heavy clay of code that this will need, I thought I should ask if there are issues I might be missing, as the local environment -- essentially "global" variables within the perimeter of the package -- would make the code a lot cleaner, and may offer some useful efficiencies in computation. Best, JN __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] query about package design
I was kind of hoping to avoid reference classes. The optimization stuff it giving me enough headaches. I've used a local environment successfully in the Rtnmin package (it is a direct conversion from my brother's TN Matlab package, which was able to use "globals" there). JN On 15-07-10 04:17 PM, Hadley Wickham wrote: > On Fri, Jul 10, 2015 at 12:50 PM, ProfJCNash wrote: >> I have a general question about appropriate design for a fairly >> complicated package, as I am redesigning and rebuilding the optimx >> package. It will get a new name as it appears that the calls will change >> in order to accommodate new functionality. I plan to make it >> fairly easy to add new optimization (function minimization) tools. >> >> The query is whether to use an environment to hold all the common >> objects (functions, scaled functions, gradients, scaled gradients, >> hessians, scaled hessians, parameters, scaled parameters, program >> controls, algorithm tuning parameters, constraints, fixed parametes, >> some function value history, etc.) The alternative is a set of very >> long calls, especially when the function needing a quantity may be a >> couple of layers below the routine that creates or sets the values. >> >> The negative side is that the functions are not portable outside the >> package, so would not be exported. >> >> Before I dig into the heavy clay of code that this will need, I thought >> I should ask if there are issues I might be missing, as the local >> environment -- essentially "global" variables within the perimeter of >> the package -- would make the code a lot cleaner, and may offer some >> useful efficiencies in computation. > > If you want to store the same set of things for many optimisers, you > might want to consider using reference classes or R6. > > Hadley > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Appropriate place to post about CRAN check environments etc.
There has been some disagreement on where it is appropriate to post questions about package checking procedures, including the building of the environment e.g., R-devel under Linux Mint. In looking at https://www.r-project.org/mail.html, it seems to me that the procedures belong with r-package-devel, but there doesn't seem to be a good home for the consequent need to build R-devel to do this. Have I missed the appropriate list? It seems to me that the volume of queries of this sort, and the success of WinBuilder, suggest we could seriously use similar a Linbuilder and MacBuilder (and possibly others). There's a lot of duplicated effort being wasted on the R-devel side in particular. Is there sufficient interest to - make the effort to emulate Winbuilder for Linux and/or Mac - coordinate the volunteer effort - fund/support the necessary infrastructure (it could be worth a modest contribution to save effort)? For the record, I'm willing to participate. I've managed to set up Linux Mint VirtualBox instances that run R current and R devel for testing, though I find I must do more work than I'd like to maintain things, likely as a result of my own limited skills. JN __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Definition of "reverse imports"
I noted that my nlmrt package on CRAN has package usl as a "reverse imports". In a modest search I have yet to find a definition of the term. Does anyone have a pointer? JN __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Definition of "reverse imports"
Thanks. Just wondered if there were something formal in case it could be important sometime. For information, I'm working on a presentation on R as an infrastructure for optimization for the Fields Institute Workshop on Nonlinear Optimization Algorithms and Industrial Applications http://www.fields.utoronto.ca/activities/15-16/algorithms If any developers have something in the pipe that would be worth communicating, please let me know off-list. The purpose of going is to build and maintain communications with the optimization crowd. Also, in my review I've come across a few package glitches e.g., package "powell" won't install because of something untoward in printf() functions. I'll report this in detail when R 3.3 comes in the Linux Mint update if there is still a problem at that time. (CRAN checks are complaining about such issues, but seem to treat them as warnings rather than errors. The package date is 2006, so rather old.) Cheers, JN On 16-05-03 03:40 PM, Uwe Ligges wrote: > > > On 03.05.2016 21:31, ProfJCNash wrote: >> I noted that my nlmrt package on CRAN has package usl as a "reverse >> imports". In a modest search I have yet to find a definition of the >> term. Does anyone have a pointer? > > That means usl imports from your nlmrt package. > > Best, > Uwe Ligges > > >> >> JN >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] duplicate function during build
In trying to rationalize some files in a package I'm working on, I copied a function from one file to another, but forgot to change the name of one of them. It turns out the name of the file containing the "old" function was later in collation sequence than the one I was planning to be the "new" one. To debug some issues, I put some print() and cat() statements in the "new" file, but after building the package, they weren't there. Turns out the "old" function got installed, as might be expected if files processed in order. Debugging this took about 2 hours of slightly weird effort with 2 machines and 3 OS distributions before I realized the problem. It's fairly obvious that I should expect issues in this case, but not so clear how to detect the source of the problem. Question: Has anyone created a script to catch such duplicate functions from different files during build? I think a warning message that there are duplicate functions could save some time and effort. Maybe it's already there, but I saw no obvious message. In this case, I'm only working in R. I've found build.R in the R tarball, which is where I suspect such a check should go, and I'm willing to prepare a patch when I figure out how this should be done. However, it seems worth asking if anyone has needed to do this before. I've already done some searching, but the results seem to pick up quite different posts than I need. Cheers, JN __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] duplicate function during build
Thanks Sven. That indeed works. And if anyone has ideas how it could be
put into R so Windows users could benefit, I'm sure it would be useful
in checks of packages.
In other investigations of this, I realized that install.R has to
prepare the .rdb and .rdx files and at that stage duplication might be
detected. If install.R puts both versions of a duplicated name into
these files, then the lazy load of library() or require() could be a
place where detection would be useful, though only one of the names gets
actually made available for use. However, my expertise with this
internal aspect of R is rather weak.
Cheers, JN
On 16-07-23 12:04 PM, Sven E. Templer wrote:
> Despite it might help, learning/using git is not tackling this specific
> problem, I suggest code that does:
>
> sed -e 's/^[\ \t]*//' -e 's/#.*//' R/* | awk '/function/{print $1}' | sort |
> uniq -d
>
> or
>
> https://gist.github.com/setempler/7fcf2a3a737ce1293e0623d2bb8e08ed
> (any comments welcome)
>
> If one knows coding R, it might be more productive developing a tiny tool for
> that, instead of learning a new (and complex) one (as git).
>
> Nevertheless, git is great!
>
> Best wishes,
>
> Sven
>
> ---
>
> web: www.templer.se
> twitter: @setempler
>> On 23 Jul 2016, at 16:17, Hadley Wickham wrote:
>>
>> I think this sort of meta problem is best solved with svn/git because you
>> can easily see if the changes you think you made align with the changes you
>> actually made. Learning svn or git is a lot of work, but the payoff is
>> worth it.
>>
>> Hadley
>>
>> On Friday, July 22, 2016, ProfJCNash wrote:
>>
>>> In trying to rationalize some files in a package I'm working on, I
>>> copied a function from one file to another, but forgot to change the
>>> name of one of them. It turns out the name of the file containing the
>>> "old" function was later in collation sequence than the one I was
>>> planning to be the "new" one. To debug some issues, I put some print()
>>> and cat() statements in the "new" file, but after building the package,
>>> they weren't there. Turns out the "old" function got installed, as might
>>> be expected if files processed in order. Debugging this took about 2
>>> hours of slightly weird effort with 2 machines and 3 OS distributions
>>> before I realized the problem. It's fairly obvious that I should expect
>>> issues in this case, but not so clear how to detect the source of the
>>> problem.
>>>
>>> Question: Has anyone created a script to catch such duplicate functions
>>> from different files during build? I think a warning message that there
>>> are duplicate functions could save some time and effort. Maybe it's
>>> already there, but I saw no obvious message. In this case, I'm only
>>> working in R.
>>>
>>> I've found build.R in the R tarball, which is where I suspect such a
>>> check should go, and I'm willing to prepare a patch when I figure out
>>> how this should be done. However, it seems worth asking if anyone has
>>> needed to do this before. I've already done some searching, but the
>>> results seem to pick up quite different posts than I need.
>>>
>>> Cheers, JN
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>
>>
>> --
>> http://hadley.nz
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
>
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Recommendation on qr method export
Closely related to the different QR variations, Claudia Beleites and I have a very crude start on some attempts to categorize different svd approaches in R. Perhaps it's worth combining efforts with QR because of the overlap and producing a sort of enlarged vignette or even a Task View. I suggest contacting me offline (I use nashjc _at_ uottawa.ca as my working email, and the one above for mailing lists) if interested. However, I view my current effort as a useful ongoing set of notes rather than a definitive treatment of the issues. Best, JN On 16-08-03 09:16 AM, Charles Determan wrote: > Thanks for the input Peter. I suppose I never looked at lm() to see how it > was used there. Given that though, do you see any reason then to not > create an S3/S4 method if different methods are used for different > functions? I'm just looking for some design guidance from the community > here before I just implement something that may cause more confusion. > > Regards, > Charles > > On Tue, Aug 2, 2016 at 4:34 PM, Peter Dalgaard wrote: > >> Not strictly what you're asking, but at some point it may be important to >> note that the "QR" method used by lm() and friends (notably anova() and >> aov()) actually relies on successive orthogonalization. This does yield a >> QR decomposition but the reverse is not true. A generic X=QR decomposition >> does orthogonalize, but it does not necessarily hold that the first k >> columns of Q spans the same subspace as the first k columns of X. LINPACK's >> QR happens to be implemented as successive orthogonalization, but LAPACK's >> is not, so only the former is usable with lm(). >> >> So, I suppose what I am getting at is that not even lm() uses qr(), it >> calls LINPACK directly. >> >> -pd >> >> >>> On 02 Aug 2016, at 21:17 , Charles Determan >> wrote: >>> >>> Hello, >>> >>> I am currently working on an implementation of QR decomposition >> (leveraging >>> a C++ library via Rcpp). Naturally I would like to have the R syntax as >>> similar as possible to base R 'qr' function. Given the class structure >> of >>> my package my instinct was to export an S4/S3 method. >>> >>> However, the QR decomposition doesn't store the final QR matrix in the >> same >>> format as base R via LINPACK, nor does it return 'qraux', 'rank' or >> 'pivot' >>> objects but instead a 'betas' object. The final 'R' and 'Q' matrices are >>> in fact identical to those ultimately returned by qr.R or qr.Q. >>> >>> So my question is, given these differences, should I just create a >>> different function name or would creating a qr.myclass dispatch be >>> acceptable (whether S3 or S4)? I would prefer the latter as I would like >>> the classes to potentially take advantage of previously written code >> using >>> 'qr'. >>> >>> Thanks, >>> Charles >>> >>> [[alternative HTML version deleted]] >>> >>> __ >>> R-package-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> >> > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] using optimx in a package
You are calling an optimizer that wants gradients without specifying the
gradient method. I've not done any work on
optimx for a couple of years -- on R-forge I've put optimrx which has a more
maintainable design and allows more solvers
to be called using the optim() syntax, including parameter scaling, and also
offers a clearer choice of which gradient
approximation is to be used. It's possible that the initial gradient could not
be worked out, though the message talks
about the function.
I tried running the code, but there are some glitches that look like you
transmitted in HTML or otherwise have
line endings or delimiters mangled. If you can post code that will run, I'll
give it a try.
JN
On 16-10-16 02:05 PM, Glenn Schultz wrote:
> All,
>
> I am using optimx in my package to fit the term structure of interest rates.
> When I call the function from the package
> I get the following error:
>
> Error in optimx.check(par, optcfg$ufn, optcfg$ugr, optcfg$uhess, lower, :
> Cannot evaluate function at initial parameters
> Called from: optimx.check(par, optcfg$ufn, optcfg$ugr, optcfg$uhess, lower,
> upper, hessian, optcfg$ctrl, have.bounds =
> optcfg$have.bounds, usenumDeriv = optcfg$usenumDeriv, ...)
>
> However, if I run the function locally outside of the package it runs a
> provides the correct solution to the problem.
> So, the issue is the function will not run correctly when called from the
> package. Any suggestions are appreciated.
> This package is written in S4
>
> Glenn
>
> Here is a dput of the Rates Object
> structure(list(Date = c("2016-07-11", NA), ED1M = c(0.47785, 0.0833), ED3M =
> c(0.6691, 0.25), ED6M = c(0.9514, 0.5),
> USSW1 = c(0.74, 1), USSW2 = c(0.82, 2), USSW3 = c(0.88, 3), USSW4 = c(0.93, 4
> ), USSW5 = c(1, 5), USSW7 = c(1.13, 7), USSW10 = c(1.31, 10), USSW30 =
> c(1.72, 30)), .Names = c("Date", "ED1M", "ED3M",
> "ED6M", "USSW1", "USSW2", "USSW3", "USSW4", "USSW5", "USSW7", "USSW10",
> "USSW30"), row.names = 1:2, class = "data.frame")
>
>
> Requirements
>
> require(lubridate)
> require(termstrc)
> require(optimx)
>
> months.in.year = 12
> weeks.in.year = 52
> pmt.frequency = 2
> min.principal = 100
> days.in.month = 30.44
> Rates <- RatesObject #Rates(trade.date = "07-11-2016")
>
>
> Here is the function
> CalibrateCIR <- function(trade.date = character, sigma = numeric()){
>
> rates.data <- Rates(trade.date = trade.date) shortrate =
> as.numeric(rates.data[1,2])/100
>
> #set the column counter to make cashflows for termstrucutre
> ColCount <- as.numeric(ncol(rates.data))
> Mat.Years <- as.numeric(rates.data[2,2:ColCount])
> Coupon.Rate <- as.numeric(rates.data[1,2:ColCount])
> Issue.Date <- as.Date(rates.data[1,1])
>
> #initialize coupon bonds S3 class
> #This can be upgraded when bondlab has portfolio function
> ISIN <- vector()
> MATURITYDATE <- vector()
> ISSUEDATE <- vector()
> COUPONRATE <- vector()
> PRICE <- vector()
> ACCRUED <- vector()
> CFISIN <- vector()
> CF <- vector()
> DATE <- vector()
> CASHFLOWS <- list(CFISIN,CF,DATE)
> names(CASHFLOWS) <- c("ISIN","CF","DATE")
> TODAY <- vector()
> data <- list()
> TSInput <- list()
>
> ### Assign Values to List Items #
> data = NULL
> data$ISIN <- colnames(rates.data[2:ColCount])
> data$ISSUEDATE <- rep(as.Date(rates.data[1,1]),ColCount - 1)
> data$MATURITYDATE <-
> sapply(Mat.Years, function(Mat.Years = Mat.Years, Issue = Issue.Date)
> {Maturity = if(Mat.Years < 1) {
> Issue %m+% months(round(Mat.Years * months.in.year))} else {Issue %m+%
> years(as.numeric(Mat.Years))}
> return(as.character(Maturity))
> }) data$COUPONRATE <- ifelse(Mat.Years < 1, 0, Coupon.Rate) data$PRICE <-
> ifelse(
> Mat.Years < 1, (1 + (Coupon.Rate/100))^(Mat.Years * -1) * 100, 100)
> data$ACCRUED <- rep(0, ColCount -1)
>
> for(j in 1:(ColCount-1)){
> Vector.Length <- as.numeric(round(
> difftime(data[[3]][j],
> data[[2]][j],
> units = c("weeks"))/weeks.in.year,5))
>
> Vector.Length <- ifelse(round(Vector.Length) < 1, 1 , round(Vector.Length *
> pmt.frequency))
>
> data$CASHFLOWS$ISIN <- append(
> data$CASHFLOWS$ISIN, rep(data[[1]][j],Vector.Length))
>
> data$CASHFLOWS$CF <- append(
> data$CASHFLOWS$CF,
> as.numeric(
> c(rep((data[[4]][j]/100/pmt.frequency),Vector.Length-1) * min.principal,
> (min.principal + (data$COUPONRATE[j]/100/pmt.frequency)* min.principal
>
> by.months = ifelse(data[[4]][j] == 0, round(difftime(
> data[[3]][j], rates.data[1,1])/days.in.month), 6)
>
> data$CASHFLOWS$DATE <- append(
> data$CASHFLOW$DATE, seq(
> as.Date(data[[2]][j]) %m+% months(as.numeric(by.months)),
> as.Date(data[[3]][j]),
> by = as.character(paste(by.months, "months", sep = " "
>
> } #The Loop Ends here and the list is made
>
> data$TODAY <- as.Date(rates.data[1,1])
> TSInput[[as.character(rates.data[1,1])]] <- c(data)
>
> #set term strucutre input (TSInput) to class couponbonds
> class(TSInput) <- "couponbonds"
> CashFlow <- TSInput[[1]]
> CIR.CF.Matrix <<- create_cashflows_matrix(TSInput[[1]], i
[R-pkg-devel] UseR! Session: Navigating the jungle of R packages.
Navigating the Jungle of R Packages The R ecosystem has many packages in various collections, especially CRAN, Bioconductor, and GitHub. While this richness of choice speaks to the popularity and importance of R, the large number of contributed packages makes it difficult for users to find appropriate tools for their work. A session on this subject has been approved for UseR! in Brussels. The tentative structure is three short introductory presentations, followed by discussion or planning work to improve the tools available to help users find the best R package and function for their needs. The currently proposed topics are - wrapper packages that allow diverse tools that perform similar functions to be accessed by unified calls - collaborative mechanisms to create and update Task Views - search and sort tools to find packages. At the time of writing we have tentative presenters for the topics, but welcome others. We hope these presentations at useR! 2017 will be part of a larger discussion that will contribute to an increased team effort after the conference to improve the the support for R users in these areas. John Nash, Julia Silge, Spencer Graves __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
