[Rd] [GSoC student proposal] Implementation of Modified Weibull-G Family Distribution in R
Dear Brian and R team, I am Dr. Aleem and I want to participate as a student in GSoC 2014 in the development of R. I have extensive experience in Statistical research and development and I am a student of advanced statistics applications. I strongly believe that the inclusion of Modified Weibull-G Family Distribution in R will significanlty help the reseasrch community in doing reliability/survival analyses. I have expertise in these areas and I would like to be part of open source development and implement it. May I ask you for potential mentor(s) who can be my supervisor for GSoC 2014. The details of project is following: *Title of project:* Implementation of Modified Weibull -G Family of Distributions in R *Description:* This project is intended for the improvements to the life time data construction for reliability analysis by using Modified Weibull -G Family of Distributions. The main goal of this project is to utilize maximum distributions by using the Modified Weibull -G Family of Distributions for reliability/survival analysis. The probability of a device not failing prior to some time " t" is reliability function i.e. R(t). The application of Modified Weibull-G Family of Probability Distributions in reliability and maintainability is widely used by the statistical research community to summarizes the shapes of the failure density, reliability and hazard rate functions and it is important to have such functionality in R package. *Importance of Project:* The packages like Matlab are missing the important packages required to study the application of Modified Weibull-G Family of Probability Distributions. The statistical research community widely rely on the application of Weibull -G Family of Distributions. Due to the importance of the Model and its application, the inclusion of such implementation in R package is the need of the time for statistical research community. Please advise me some mentor so that I can discuss the tasks and my deliverables. Please let me know if I need to add this project to the wiki page as this is my own student idea, Thank you. Best Regards, Dr. M Aleem [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to import S3 method
Dear Helpers,
I wanted to import an S3 method from package glmnet to my own R package.
Specifically, I tried the following:
plot.glmreg=function(x, xvar=c("norm","lambda","dev"),label=FALSE,shade=TRUE,
...) UseMethod("glmnet")
I got the following message when installing my package:
Error : object 'plot.glmnet' is not exported by 'namespace:glmnet'
Is there a correct way to import?
Thanks,
Zhu
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to import S3 method
On Mar 4, 2014, at 10:21, "Wang, Zhu" wrote:
> Dear Helpers,
>
> I wanted to import an S3 method from package glmnet to my own R package.
> Specifically, I tried the following:
>
> plot.glmreg=function(x, xvar=c("norm","lambda","dev"),label=FALSE,shade=TRUE,
> ...) UseMethod("glmnet")
>
> I got the following message when installing my package:
>
> Error : object 'plot.glmnet' is not exported by 'namespace:glmnet'
>
> Is there a correct way to import?
http://cran.r-project.org/doc/manuals/R-exts.html#Specifying-imports-and-exports
>
> Thanks,
>
> Zhu
>
>
>
>
>
>[[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [PATCH] Code coverage support proof of concept
Hello,
I submit a patch for review that implements code coverage tracing in
the R interpreter.
It records the lines that are actually executed and their associated
frequency for which srcref information is available.
I perfectly understands that this patch will not make its way inside R
as it is, that they are many concerns of stability, compatibility,
maintenance and so on.
I would like to have the code reviewed, and proper guidance on how to
get this feature available at one point in R, in base R or as a
package or patch if other people are interested.
Usage
Rcov_start()
# your code to trace here
res <- Rcov_stop()
res is currently a hashed env, with traced source filenames associated
with 2-columns matrices holding the line numbers and their
frequencies.
How it works
-
I added a test in getSrcref(), that records the line numbers if code
coverage is started.
The overhead should be minimal since for a given file, subsequent
covered lines will be stored
in constant time. I use a hased env to store the occurrences by file.
I added two entry points in the utils package (Rcov_start() and Rcov_stop())
Example
-
* untar the latest R-devel and cd into it
* patch -p1 < rdev-cov-patch.txt
* ./configure [... ] && make && [sudo] make install
* install the devtools package
* run the following script using Rscript
library(methods)
library(devtools)
pkg <- download.packages('testthat', '.', repos = "http://stat.ethz.ch/CRAN";)
untar(pkg[1, 2])
Rcov_start()
test('testthat')
env <- Rcov_stop()
res <- lapply(ls(env), get, envir = env)
names(res) <- ls(env)
print(res)
This will hopefully output something like:
$`.../testthat/R/auto-test.r`
[,1] [,2]
[1,] 331
[2,] 801
$`.../testthat/R/colour-text.r`
[,1] [,2]
[1,] 181
[2,] 19 106
[3,] 20 106
[4,] 22 106
[5,] 23 106
[6,] 401
[7,] 591
[8,] 701
[9,] 71 106
...
Karl Forner
Disclaimer
-
There are probably bugs and ugly statements, but this is just a proof
of concept. This is untested and only run on a linux x86_64
diff -ruN R-devel/src/library/utils/man/Rcov_start.Rd
R-devel-cov/src/library/utils/man/Rcov_start.Rd
--- R-devel/src/library/utils/man/Rcov_start.Rd 1970-01-01 01:00:00.0
+0100
+++ R-devel-cov/src/library/utils/man/Rcov_start.Rd 2014-03-05
16:07:45.907596276 +0100
@@ -0,0 +1,26 @@
+% File src/library/utils/man/Rcov_start.Rd
+% Part of the R package, http://www.R-project.org
+% Copyright 1995-2010 R Core Team
+% Distributed under GPL 2 or later
+
+\name{Rcov_start}
+\alias{Rcov_start}
+\title{Start Code Coverage analysis of R's Execution}
+\description{
+ Start Code Coverage analysis of the execution of \R expressions.
+}
+\usage{
+Rcov_start(nb_lines = 1L, growth_rate = 2)
+}
+\arguments{
+ \item{nb_lines}{
+Initial max number of lines per source file.
+ }
+ \item{growth_rate}{
+growth factor of the line numbers vectors per filename.
+If a reached line number L is greater than nb_lines, the vector will
+be reallocated with provisional size of growth_rate * L.
+ }
+}
+
+\keyword{utilities}
diff -ruN R-devel/src/library/utils/man/Rcov_stop.Rd
R-devel-cov/src/library/utils/man/Rcov_stop.Rd
--- R-devel/src/library/utils/man/Rcov_stop.Rd 1970-01-01 01:00:00.0
+0100
+++ R-devel-cov/src/library/utils/man/Rcov_stop.Rd 2014-03-03
16:14:25.883440716 +0100
@@ -0,0 +1,20 @@
+% File src/library/utils/man/Rcov_stop.Rd
+% Part of the R package, http://www.R-project.org
+% Copyright 1995-2010 R Core Team
+% Distributed under GPL 2 or later
+
+\name{Rcov_stop}
+\alias{Rcov_stop}
+\title{Start Code Coverage analysis of R's Execution}
+\description{
+ Start Code Coverage analysis of the execution of \R expressions.
+}
+\usage{
+Rcov_stop()
+}
+
+\value{
+ a named list of integer vectors holding occurrences counts (line number,
frequency)
+ , named after the covered source file names.
+}
+\keyword{utilities}
diff -ruN R-devel/src/library/utils/NAMESPACE
R-devel-cov/src/library/utils/NAMESPACE
--- R-devel/src/library/utils/NAMESPACE 2013-09-10 03:04:59.0 +0200
+++ R-devel-cov/src/library/utils/NAMESPACE 2014-03-03 16:18:48.407430952
+0100
@@ -1,7 +1,7 @@
# Refer to all C routines by their name prefixed by C_
useDynLib(utils, .registration = TRUE, .fixes = "C_")
-export("?", .DollarNames, CRAN.packages, Rprof, Rprofmem, RShowDoc,
+export("?", .DollarNames, CRAN.packages, Rcov_start, Rcov_stop, Rprof,
Rprofmem, RShowDoc,
RSiteSearch, URLdecode, URLencode, View, adist, alarm, apropos,
aregexec, argsAnywhere, assignInMyNamespace, assignInNamespace,
as.roman, as.person, as.personList, as.relistable, aspell,
diff -ruN R-devel/src/library/utils/R/Rcov.R
R-devel-cov/src/library/utils/R/Rcov.R
--- R-devel/src/library/utils/R/Rcov.R 1970-01-01 01:00:00.0 +0100
+++ R-devel-cov/src/library/utils/R/Rcov.R 2014-03-03 16:08:45.739453368
+0100
[Rd] Sweave provides a misleading error when vignette engine not fully specified
Trying to Stangle / Sweave a file
$ cat vignette.Rnw
%\VignetteEngine{knitr}
\documentclass{article}
\begin{document}
\end{document}
results in a misleading error message:
~/tmp$ R CMD Stangle vignette.Rnw
Error: Vignette engine package not specified
Execution halted
when what is missing is the full specification knitr::knitr; 'vignette engine
package and function not specified' ? Also it's somehow unfortunate that the
vignette builds when in a package/vignettes directory, but not as a stand-alone
document.
Also for what its worth Sweave'ing still fails to produce graphics output
https://stat.ethz.ch/pipermail/r-devel/2014-February/068414.html
$ R --version|head -n 3
R Under development (unstable) (2014-03-05 r65124) -- "Unsuffered Consequences"
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
Martin
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave provides a misleading error when vignette engine not fully specified
On 05/03/2014 11:38 AM, Martin Morgan wrote:
Trying to Stangle / Sweave a file
$ cat vignette.Rnw
%\VignetteEngine{knitr}
\documentclass{article}
\begin{document}
\end{document}
results in a misleading error message:
~/tmp$ R CMD Stangle vignette.Rnw
Error: Vignette engine package not specified
Execution halted
I don't see that as misleading. The code can't figure out where the
knitr engine comes from, and it's telling you that.
when what is missing is the full specification knitr::knitr; 'vignette engine
package and function not specified' ? Also it's somehow unfortunate that the
vignette builds when in a package/vignettes directory, but not as a stand-alone
document.
A package can declare the vignette building package in its DESCRIPTION
file. If it's a standalone Sweave document, it needs to be declared in
the document itself. (It's also possible to declare it on the Stangle
command line, but you'll still need the fully qualified name, e.g.
R CMD Stangle --engine=knitr::knitr vignette.Rnw
It might be possible to set up R to automatically load knitr first (e.g.
by putting it in your list of R_DEFAULT_PACKAGES); I haven't tried
that. But somehow you need to tell R where the knitr engine lives.
Also for what its worth Sweave'ing still fails to produce graphics output
Now that sounds unrelated.
Duncan Murdoch
https://stat.ethz.ch/pipermail/r-devel/2014-February/068414.html
$ R --version|head -n 3
R Under development (unstable) (2014-03-05 r65124) -- "Unsuffered Consequences"
Copyright (C) 2014 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] forking a CRAN project
Micheal, Keep in mind that the author of the package can give you a copy under any conditions that they choose, they are not bound by the GPL. Simply send you code from their own source which is "upstream" of the GPL copy. (The copy out on CRAN propogates strictly via GPL however). You could for instance start a new package de novo. This may or may not make sense in your case, but I wanted to point out the flexibility. A version of rpart has twice been bundled into commercial products via this route, where the user didn't want to be under the GPL. None in the last 8-10 years; as Brian Ripley's and my contributions to rpart are now far too comingled to define a non-gpl code base. I'll also note that in both those cases my employer took the quite defensible position that contributions to a for profit company are not free of charge. On 03/05/2014 05:00 AM, r-devel-requ...@r-project.org wrote: There is a CRAN package licensed just as "GPL", say, XX, I want to use in a book. But I've needed to modify the package to make it do what I need for expository purposes. The package author(s) are amenable to my modifications, but probably unlikely to incorporate them into the CRAN version any time soon. Am I allowed, under GPL, to create a new version of the package, say XX2, in a public repository such as R-Forge or github? I would, of course, maintain their authorship, though perhaps take over the maintainer role. For my purposes in the book, I don't necessarily need to release my version to CRAN; just a public repo a reader could download from. -Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Constructor/extractor.
Hi Rolf, Barry, On 03/04/2014 08:08 AM, Barry Rowlingson wrote: On Tue, Mar 4, 2014 at 1:47 AM, Rolf Turner wrote: Questions: == (2) Even if there are no such functions, is there anything intrinsically *wrong* with having a function possessing this somewhat schizophrenic nature? Is it likely to cause confusion, induce syntactical mistakes, create errors, or produce wrong results? Any thoughts, comments, insights or suggestions gratefully received. I don't see why you can't conceptually think of w = owin(some_ppp_object) as an owin "Constructor" rather than an "Accessor". Its "constructing" (and returning) an owin from an object, it just happens to be as simple as getting a component from that object. The raster package has the 'extent' function - you can create an extent with extent(xmin,xmax,,,etc), get the extent of a raster with extent(r), or set the extent of a raster with extent(r1) <- extent(r2), so I don't see any problem with: w1 = owin(poly=...) # construct polygon owin ppp1 = ppp(x,y,window=w1) ppp2 = ppp(x,y, window=owin(ppp1)) # construct window from ppp object owin(ppp1) = owin(ppp2) # give ppp1 the owin of ppp2 That all reads pretty nicely. As long as owin(...) returns an observation window and owin<-(...) assigns an observation window to an object that can validly have one, I don't think you can go wrong. I've probably already tried to do "owin(ppp1)=..." a few times... I agree with Barry. Once you realize there is no clear line between constructor and extractor (conceptually every function can actually be thought of as a constructor), then re-using the same function name (via methods of a generic function) doesn't sound too bad. An example of this design is the strand() generic in Bioconductor: can be used to get or set the strand factor of an object containing such a component (e.g. a GRanges object), and also for constructing a strand factor from different kinds of input (character, logical, integer vector, etc...) Cheers, H. Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
