Hi Bob I had also started working on SuppDists a couple of months ago as I needed to expose some of the distributions at C-level for use in another package. Perhaps I/we could create a GitHub repo and collaborate on this? I’m happy for you to take the lead, but a job shared is a job halved and all that…
We have an institutional (my section at the University of Copenhagen) GitHub repo that I could use to set it up. Cheers, Matt > On 29 Sep 2019, at 23:27, Bob Rudis <b...@rud.is> wrote: > > Ah, I spoke too soon. I started putting the demo code into a test suite and > ran one check with valgrind and — sure enough — there's def more issues (a > cpl functions) than the overt/easy ones (and, I went back to the check > results page and, also sure enough, they're there, too). They look to be > fairly straightforward to resolve but it's going to take a bit longer than > "this week", but I'm not rescinding the volunteering. > > -Bob > >> On Sep 29, 2019, at 17:19, Bob Rudis <b...@rud.is> wrote: >> >> Or, a crazy person (me) cld volunteer to keep this running and get it back >> on CRAN. >> >> I fixed the severe warning and also added C-side registration code. >> >> The pkg is monolithic but the C code is super straightforward (a is the R >> code). >> >> Unless someone can think of a reason not to, I can submit this to CRAN this >> week and get the source up on social coding sites. >> >> It looks like Jerome Braun did this for another one of Bob Wheeler's pkgs, >> so there's some existing precedent for doing this. >> >> -Bob >> >>> On Sep 29, 2019, at 16:22, Ben Bolker <bbol...@gmail.com> wrote: >>> >>> >>> >>> On 2019-09-25 3:26 a.m., Martin Maechler wrote: >>>>>>>>> Ben Bolker >>>>>>>>> on Tue, 24 Sep 2019 20:09:55 -0400 writes: >>>> >>>>> SuppDists is orphaned on CRAN (and has been since 2013). >>>>> https://cran.r-project.org/web/checks/check_results_.html >>>> >>>>> Oddly, the simulate method for the inverse.gaussian family >>>>> [inverse.gaussian()$simulate] depends (in a loose sense) on SuppDists >>>>> (it fails if the SuppDists namespace is not available: >>>> >>>>> if (!requireNamespace("SuppDists", quietly = TRUE)) >>>>> stop("need CRAN package 'SuppDists' for simulation from the >>>>> 'inverse.gaussian' family") >>>> >>>> >>>>> The statmod package also implements inverse gaussian d/p/q/r functions >>>>> <https://journal.r-project.org/archive/2016-1/giner-smyth.pdf>. It is >>>>> lightweight (depends on R >= 3.0.0, imports only base packages [stats >>>>> and graphics]) and has been around for a long time (archived versions on >>>>> CRAN go back to 2003). >>>> >>>>> Would it make sense to replace the call to SuppDists::rinvGauss with a >>>>> corresponding call to statmod::rinvgauss ? Would a patch be considered? >>>> >>>>> Ben Bolker >>>> >>>> I'd say "yes" & "yes". >>>> >>>> "Base" code weekly depending on CRAN packages (apart from >>>> formally 'Recommended' ones) is somewhat sub-optimal in any >>>> case, ((but possibly still the best thing, given reality >>>> [maintenance efforts, copyrights, ...])), >>>> but your proposal seems a "uniformly not worse" change >>>> ((and I have very much liked delving into parts of Gordon >>>> Smyth's textbook on GLMs as a really nice mixture / in-between >>>> of rigorous math and applied stats)) >>> >>> I did actually think of a reason *not* to do this. >>> >>> The resulting random deviates generated by statmod::rinvgauss aren't >>> exactly the same as those from SuppDists::rinvGauss (same algorithm, but >>> I guess they use sufficiently different internal machinery), so this >>> could break exact backward compatibility for any code that uses >>> simulate() for inverse-Gaussian models. Still might be worth doing, but >>> now the change is *not* "uniformly not worse". >>> >>> An alternative (which would remove the dependency on a CRAN package) >>> would be to pull the code of statmod::rinvgauss into R (which would be >>> allowed - statmod is GPL 2/3 - but of course it would be polite to ask). >>> The downside to this solution would be adding the maintenance burden of >>> this code ... >>> >>>> >>>> Martin Maechler >>>> ETH Zurich and R Core >>>> >>> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
