depending on orphaned packages?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

depending on orphaned packages?

bbolker
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: depending on orphaned packages?

Martin Maechler
>>>>> 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))

Martin Maechler
ETH Zurich and R Core

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: depending on orphaned packages?

bbolker


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
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: depending on orphaned packages?

Bob Rudis
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 <[hidden email]> 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
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: depending on orphaned packages?

Matt Denwood
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel