[Rd] depending on orphaned packages?

[Bob Rudis]

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 <bob using 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 <bbolker using 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 using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>