From md @end|ng |rom @und@ku@dk  Mon Sep 30 09:09:04 2019
From: md @end|ng |rom @und@ku@dk (Matt Denwood)
Date: Mon, 30 Sep 2019 07:09:04 +0000
Subject: [Rd] depending on orphaned packages?
In-Reply-To: <E435A4E2-B963-42A6-8586-C6D31AED8A89@rud.is>
References: <b1fd1b08-c111-57f1-2cdd-937a3732e081@gmail.com>
 <23947.5769.742626.892720@stat.math.ethz.ch>
 <fac3a3cc-f197-0866-e4d0-0bea003ff4e4@gmail.com>
 <E5E5B525-D16C-4BBD-B528-B110FC5C4104@rud.is>
 <E435A4E2-B963-42A6-8586-C6D31AED8A89@rud.is>
Message-ID: <993145AB-6853-47A9-82F2-0348E5DC4A74@sund.ku.dk>

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



[Rd] depending on orphaned packages?
Matt Denwood