Re: [Rd] R CMD build should fail early for old package versions?
On 30/09/2019 5:25 p.m., Toby Hocking wrote: Hi all, Today I had an R CMD build that failed while building a vignette because the vignette needs tidyr (>= 1.0, declared in DESCRIPTION Suggests) but my system had a previous version installed. It did not take me too long to figure out the issue (solved by upgrading tidyr) but it would have been even faster / easier if R CMD build failed early, with an error message that says something like "Can not build package XXX because it Suggests: tidyr (>= 1.0) but tidyr 0.8.3 is installed" Is that possible? If you list a package in Suggests, your package should work (perhaps with some limitations) without the suggested one. Unfortunately for you, the limitation "can't rebuild the vignettes" is incompatible with building the package, but I don't think there's anything you can put in the DESCRIPTION file to indicate this. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD build should fail early for old package versions?
Hi all, Today I had an R CMD build that failed while building a vignette because the vignette needs tidyr (>= 1.0, declared in DESCRIPTION Suggests) but my system had a previous version installed. It did not take me too long to figure out the issue (solved by upgrading tidyr) but it would have been even faster / easier if R CMD build failed early, with an error message that says something like "Can not build package XXX because it Suggests: tidyr (>= 1.0) but tidyr 0.8.3 is installed" Is that possible? Toby [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] speed up R_IsNA, R_IsNaN for vector input
Dear Tomas, I was thinking it is because of taking ieee_double y; out from the loop, and re-using across iterations. Now I checked that was not the reason of speed up. So as you wrote, it was only due to inlining. I am surprised the difference is so significant. Thank you, Jan On Mon, Sep 30, 2019 at 10:31 AM Tomas Kalibera wrote: > > On 9/29/19 1:09 PM, Jan Gorecki wrote: > > 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. > > Dear Jan, > > Looking at your examples, I just see you have hand-inlined > R_IsNA/R_IsNaN, or is there anything more? In principle we could put > R_IsNA, R_IsNAN into Rinlinedfuns to allow inlining across compilation > modules, but we can't put all functions there - so there would have to > be a clear case for a performance problem in some specific function in a > different module. > > If you were curious there are optimized checks for non-finite values in > vectors in array.c, which are used for matrix multiplication before > calling to BLAS. These have to be fast and the optimization is biased > towards the case that such values are rare and that it is ok to > sometimes say "there may be non-finite values" even when in fact they > are not. > > Best > Tomas > > > 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 > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] speed up R_IsNA, R_IsNaN for vector input
On 9/29/19 1:09 PM, Jan Gorecki wrote: 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. Dear Jan, Looking at your examples, I just see you have hand-inlined R_IsNA/R_IsNaN, or is there anything more? In principle we could put R_IsNA, R_IsNAN into Rinlinedfuns to allow inlining across compilation modules, but we can't put all functions there - so there would have to be a clear case for a performance problem in some specific function in a different module. If you were curious there are optimized checks for non-finite values in vectors in array.c, which are used for matrix multiplication before calling to BLAS. These have to be fast and the optimization is biased towards the case that such values are rare and that it is ok to sometimes say "there may be non-finite values" even when in fact they are not. Best Tomas 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 __ 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?
On 9/29/19 6:12 PM, 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 ;-)
Please note that it is not a good practice to test for these things in
unit tests. Every system has some specified (or "documented" - in R)
behavior, and then some unspecified. Programs must not depend on the
unspecified behavior. If your programs do, then they should be fixed not
to do so. If they do not, then there is no point in testing whether the
unspecified behavior changed or seems to have changed. Also the
existence of these tests often wastes time of the people who find out
when these tests start failing (can be your time, but also CRAN, RCore
or anyone else's). It is of course a good thing to check inputs in
functions, e.g. in the actual code that uses an "option", to the point
that is needed for correct execution of the code, but that neither that
check nor the code should expect more than what is specified.
Best
Tomas
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] depending on orphaned packages?
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 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 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
