Re: [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  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  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
 .  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

Re: [Rd] 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  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
>>> .  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

Re: [Rd] depending on orphaned packages?

[Ben Bolker]

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
> > .  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

Re: [Rd] typeof(getOption("warn")) is "integer" instead of "double" in R unstable (2019-09-27 r77229)? Reproducible?

[Duncan Murdoch]

On 29/09/2019 12:12 p.m., nos...@altfeld-im.de wrote:

Thanks a lot for pointing out the reason
(and yes, I am testing quite to stringent in this case - it's my old testing 
disease ;-)

For other readers:

The R-devel NEWS is a good source to find possible change reasons:

https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html


And if you want to follow along, you can get it as an RSS feed from 
.  If you don't know what 
an RSS feed is, see feedly.com.


Duncan Murdoch




On Sun, 2019-09-29 at 08:33 -0400, Duncan Murdoch wrote:

On 29/09/2019 7:55 a.m., nos...@altfeld-im.de wrote:

Hi,

I have a failing unit test in my package tryCatchLog on the CRAN build 
infrastructure
(https://cran.r-project.org/web/checks/check_results_tryCatchLog.html)
with "R Under development (unstable) (2019-09-27 r77229)"
and the unit tests just ensures consistent behaviour of R (not of my package) 
as a precondition:

The failing unit test is caused by

typeof(getOption("warn"))
[1] "integer"


but it should be

[1] "double"


This is related to this bug fix:

CHANGES IN R 3.6.1 patched BUG FIXES

  ‘options(warn=1e11)’ is an error now, instead of later leading to C
stack overflow because of infinite recursion.

which occurred in rev 77226.  It explicitly coerces the warn value to
integer.



I have no build infrastructure for dev and want to find out if this is caused by
- my mistake
- changes in the R dev version
- the new C compilers used (correlates with the failing unit test)


It is changes in the dev and patched versions, and also your mistake:
your test shouldn't be so stringent.  The docs don't say that the value
has to be a double; in fact, they suggest it should be a whole number
value (talking about 0, 1, "2 or more", not about what would happen with
options(warn = pi/2), for example.

In older versions, options(warn = pi/2) is treated the same as
options(warn = 1), and in the new version, it is displayed as 1 as well.

Duncan Murdoch


Can somebody (having the R dev version available) please help me and answer the 
result of


typeof(getOption("warn"))


using "R Under development (unstable) (2019-09-27 r77229)" or newer?

Thanks a lot and sorry for the "noise"!

Jurgen

PS: These R (dev) versions did work as expected (returning "double") but were 
also using older C compilers:
- R Under development (unstable) (2019-09-20 r77199)
- R Under development (unstable) (2019-09-22 r77202)
- R Under development (unstable) (2019-09-25 r77217)
- R version 3.6.1 Patched (2019-09-25 r77224)
- R version 3.6.1 (2019-07-05)
- R version 3.6.0 beta (2019-04-15 r76395)
- R version 3.5.3 (2019-03-11)
- R version 3.5.2 (2018-12-20)

__
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

Re: [Rd] typeof(getOption("warn")) is "integer" instead of "double" in R unstable (2019-09-27 r77229)? Reproducible?

[nos...@altfeld-im.de]

Thanks a lot for pointing out the reason
(and yes, I am testing quite to stringent in this case - it's my old testing 
disease ;-)

For other readers:

The R-devel NEWS is a good source to find possible change reasons:

https://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html


On Sun, 2019-09-29 at 08:33 -0400, Duncan Murdoch wrote:
> On 29/09/2019 7:55 a.m., nos...@altfeld-im.de wrote:
> > Hi,
> > 
> > I have a failing unit test in my package tryCatchLog on the CRAN build 
> > infrastructure
> > (https://cran.r-project.org/web/checks/check_results_tryCatchLog.html)
> > with "R Under development (unstable) (2019-09-27 r77229)"
> > and the unit tests just ensures consistent behaviour of R (not of my 
> > package) as a precondition:
> > 
> > The failing unit test is caused by
> > > typeof(getOption("warn"))
> > > [1] "integer"
> > 
> > but it should be
> > > [1] "double"
> 
> This is related to this bug fix:
> 
> CHANGES IN R 3.6.1 patched BUG FIXES
> 
>  ‘options(warn=1e11)’ is an error now, instead of later leading to C 
> stack overflow because of infinite recursion.
> 
> which occurred in rev 77226.  It explicitly coerces the warn value to 
> integer.
> 
> 
> > I have no build infrastructure for dev and want to find out if this is 
> > caused by
> > - my mistake
> > - changes in the R dev version
> > - the new C compilers used (correlates with the failing unit test)
> 
> It is changes in the dev and patched versions, and also your mistake: 
> your test shouldn't be so stringent.  The docs don't say that the value 
> has to be a double; in fact, they suggest it should be a whole number 
> value (talking about 0, 1, "2 or more", not about what would happen with 
> options(warn = pi/2), for example.
> 
> In older versions, options(warn = pi/2) is treated the same as 
> options(warn = 1), and in the new version, it is displayed as 1 as well.
> 
> Duncan Murdoch
> > 
> > Can somebody (having the R dev version available) please help me and answer 
> > the result of
> > 
> > > typeof(getOption("warn"))
> > 
> > using "R Under development (unstable) (2019-09-27 r77229)" or newer?
> > 
> > Thanks a lot and sorry for the "noise"!
> > 
> > Jurgen
> > 
> > PS: These R (dev) versions did work as expected (returning "double") but 
> > were also using older C compilers:
> > - R Under development (unstable) (2019-09-20 r77199)
> > - R Under development (unstable) (2019-09-22 r77202)
> > - R Under development (unstable) (2019-09-25 r77217)
> > - R version 3.6.1 Patched (2019-09-25 r77224)
> > - R version 3.6.1 (2019-07-05)
> > - R version 3.6.0 beta (2019-04-15 r76395)
> > - R version 3.5.3 (2019-03-11)
> > - R version 3.5.2 (2018-12-20)
> > 
> > __
> > 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

Re: [Rd] typeof(getOption("warn")) is "integer" instead of "double" in R unstable (2019-09-27 r77229)? Reproducible?

[Duncan Murdoch]

On 29/09/2019 7:55 a.m., nos...@altfeld-im.de wrote:

Hi,

I have a failing unit test in my package tryCatchLog on the CRAN build 
infrastructure
(https://cran.r-project.org/web/checks/check_results_tryCatchLog.html)
with "R Under development (unstable) (2019-09-27 r77229)"
and the unit tests just ensures consistent behaviour of R (not of my package) 
as a precondition:

The failing unit test is caused by

typeof(getOption("warn"))
[1] "integer"


but it should be

[1] "double"




This is related to this bug fix:

CHANGES IN R 3.6.1 patched BUG FIXES

‘options(warn=1e11)’ is an error now, instead of later leading to C 
stack overflow because of infinite recursion.


which occurred in rev 77226.  It explicitly coerces the warn value to 
integer.




I have no build infrastructure for dev and want to find out if this is caused by
- my mistake
- changes in the R dev version
- the new C compilers used (correlates with the failing unit test)


It is changes in the dev and patched versions, and also your mistake: 
your test shouldn't be so stringent.  The docs don't say that the value 
has to be a double; in fact, they suggest it should be a whole number 
value (talking about 0, 1, "2 or more", not about what would happen with 
options(warn = pi/2), for example.


In older versions, options(warn = pi/2) is treated the same as 
options(warn = 1), and in the new version, it is displayed as 1 as well.


Duncan Murdoch


Can somebody (having the R dev version available) please help me and answer the 
result of


typeof(getOption("warn"))


using "R Under development (unstable) (2019-09-27 r77229)" or newer?

Thanks a lot and sorry for the "noise"!

Jurgen

PS: These R (dev) versions did work as expected (returning "double") but were 
also using older C compilers:
- R Under development (unstable) (2019-09-20 r77199)
- R Under development (unstable) (2019-09-22 r77202)
- R Under development (unstable) (2019-09-25 r77217)
- R version 3.6.1 Patched (2019-09-25 r77224)
- R version 3.6.1 (2019-07-05)
- R version 3.6.0 beta (2019-04-15 r76395)
- R version 3.5.3 (2019-03-11)
- R version 3.5.2 (2018-12-20)

__
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

[Rd] typeof(getOption("warn")) is "integer" instead of "double" in R unstable (2019-09-27 r77229)? Reproducible?

[nos...@altfeld-im.de]

Hi,

I have a failing unit test in my package tryCatchLog on the CRAN build 
infrastructure
(https://cran.r-project.org/web/checks/check_results_tryCatchLog.html)
with "R Under development (unstable) (2019-09-27 r77229)"
and the unit tests just ensures consistent behaviour of R (not of my package) 
as a precondition:

The failing unit test is caused by
> typeof(getOption("warn"))
> [1] "integer"

but it should be
> [1] "double"

I have no build infrastructure for dev and want to find out if this is caused by
- my mistake
- changes in the R dev version
- the new C compilers used (correlates with the failing unit test)

Can somebody (having the R dev version available) please help me and answer the 
result of

> typeof(getOption("warn"))

using "R Under development (unstable) (2019-09-27 r77229)" or newer?

Thanks a lot and sorry for the "noise"!

Jurgen

PS: These R (dev) versions did work as expected (returning "double") but were 
also using older C compilers:
- R Under development (unstable) (2019-09-20 r77199)
- R Under development (unstable) (2019-09-22 r77202)
- R Under development (unstable) (2019-09-25 r77217)
- R version 3.6.1 Patched (2019-09-25 r77224)
- R version 3.6.1 (2019-07-05)
- R version 3.6.0 beta (2019-04-15 r76395)
- R version 3.5.3 (2019-03-11)
- R version 3.5.2 (2018-12-20)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] speed up R_IsNA, R_IsNaN for vector input

[Jan Gorecki]

Dear R developers,

I spotted that R_isNA and R_IsNaN could be improved when applied on a
vector where we could take out small part of their logic, run it once,
and then reuse inside the loop.
I setup tiny plain-C experiment. Taking R_IsNA, R_IsNaN from R's
arithmetic.c, and building R_vIsNA and R_vIsNaN accordingly.
For double input of size 1e9 (having some NA and NaN) I observed
following timings:

R_IsNA6.729s
R_vIsNA   4.386s

R_IsNaN   6.874s
R_vIsNaN  4.479s

ISNAN 4.392s

It looks like R_vIsN(A|aN) are close to ISNAN (which just wraps to
math.h::isnan).
Should I follow up with a patch?

The experiment is a single nan.c file of 127 lines (includes R C
funs). Large enough to not paste in the email. Here is the link:
https://gist.github.com/jangorecki/c140fed3a3672620c1e2af90a768d785

Run it as:

gcc nan.c -lm
./a.out R_vIsNA 8
./a.out R_IsNA 8
./a.out R_vIsNaN 8
./a.out R_IsNaN 8
./a.out ISNAN 8

Best regards,
Jan Gorecki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel