[Rd] Announcing the R Documentation Task Force

cross-posting announcement to R-Announce, R-devel and R-package-devel. The R Consortium recently announced (https://www.r-consortium.org/news/blogs/2016/08/r-consortium-funds-three-projects-july) support of the R Documentation Task Force. The task force aims to design and implement the next

Re: [Rd] table(exclude = NULL) always includes NA

Looking at the code of function 'table' in R devel r71227, I see that the part "remove NA level if it was added only for excluded in factor(a, exclude=.)" is not quite right. In is.na(a) <- match(a0, c(exclude,NA), nomatch=0L) , I think that what is intended is

Re: [Rd] Different results for tan(pi/2) and tanpi(1/2)

Other examples of functions like this are log1p(x), which is log(1+x) accurate for small x, and expm1(x), which is exp(x)-1 accurate for small x. E.g., > log1p( 1e-20 ) [1] 1e-20 > log( 1 + 1e-20 ) [1] 0 log itself cannot be accurate here because the problem is that 1 == 1 + 1e-20 in

Re: [Rd] Different results for tan(pi/2) and tanpi(1/2)

If pi were stored and computed to infinite precision then yes we would expect tan(pi/2) to be NaN, but computers in general and R specifically don't store to infinite precision (some packages allow arbitrary (but still finite) precision) and irrational numbers cannot be stored exactly. So you

Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays

Martin et al., I seem to be in the minority here, so I won't belabor the point too much, but one last response inline: On Thu, Sep 8, 2016 at 11:51 PM, Martin Maechler wrote: > Thank you, Gabe and Bill, > > for taking up the discussion. > > > William Dunlap

Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays

On 09/08/2016 05:06 PM, robin hankin wrote: Could we take a cue from min() and max()? x <- 1:10 min(x[x>7]) [1] 8 min(x[x>11]) [1] Inf Warning message: In min(x[x > 11]) : no non-missing arguments to min; returning Inf As ?min says, this is implemented to preserve transitivity, and

Re: [Rd] Different results for tan(pi/2) and tanpi(1/2)

tanpi(x) should be more accurate than tan(pi*x), especially near multiples of pi/2. Bill Dunlap TIBCO Software wdunlap tibco.com On Fri, Sep 9, 2016 at 11:55 AM, Hans W Borchers wrote: > The same argument would hold for tan(pi/2). > I don't say the result 'NaN' is wrong,

Re: [Rd] Different results for tan(pi/2) and tanpi(1/2)

The same argument would hold for tan(pi/2). I don't say the result 'NaN' is wrong, but I thought, tan(pi*x) and tanpi(x) should give the same result. Hans Werner On Fri, Sep 9, 2016 at 8:44 PM, William Dunlap wrote: > It should be the case that tan(pi*x) != tanpi(x) in many

Re: [Rd] Different results for tan(pi/2) and tanpi(1/2)

It should be the case that tan(pi*x) != tanpi(x) in many cases - that is why it was added. The limits from below and below of the real function tan(pi*x) as x approaches 1/2 are different, +Inf and -Inf, so the limit is not well defined. Hence the computer function tanpi(1/2) ought to return

Re: [Rd] Different results for tan(pi/2) and tanpi(1/2)

On Fri, Sep 9, 2016 at 12:24 PM, Hans W Borchers wrote: > As the subject line says, we get different results for tan(pi/2) and > tanpi(1/2), though this should not be the case: > > > tan(pi/2) > [1] 1.633124e+16 > > > tanpi(1/2) > [1] NaN > Warning

[Rd] Different results for tan(pi/2) and tanpi(1/2)

As the subject line says, we get different results for tan(pi/2) and tanpi(1/2), though this should not be the case: > tan(pi/2) [1] 1.633124e+16 > tanpi(1/2) [1] NaN Warning message: In tanpi(1/2) : NaNs produced By redefining tanpi with sinpi and cospi, we can get

[Rd] R-intro: function 'stderr' and 'sd'

In "An Introduction to R" Version 3.3.1, in "4.2 The function tapply() and ragged arrays", after stderr <- function(x) sqrt(var(x)/length(x)) , there is a note in brackets: Writing functions will be considered later in [Writing your own functions], and in this case was unnecessary as R also has

Re: [Rd] forgive possible repost: alternate bzip2 library

Dirk, thanks for your reply ... yes configure.ac, definitely. OK, mature build system ... that's a warning indeed, though of course some dependency libs already are treated like this, bitmaps/jpg for example: configure.ac ## Bitmap headers and libraries. if test -n "${PKGCONF}"; then R_BITMAPS2

Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays

> Radford Nea: > > So it may make more sense to move towards consistency in the > > permissive direction, rather than the restrictive direction. > > > That would mean allowing matrix(1,1,1) < (1:2), and maybe also things > > like matrix(1,2,2)+(1:8). > > Martin Maechler: >

Re: [Rd] forgive possible repost: alternate bzip2 library

On 9 September 2016 at 12:21, Ramón Fallon wrote: | I am resubmitting a question, mainly because I suspect I may have | inadvertently cancelled it, while it was awaiting moderator approval. | | It's about manually compiling R-3.3.1 and using, not the standard system's | (ver 1.0.5), but an

[Rd] forgive possible repost: alternate bzip2 library

Hi, I am resubmitting a question, mainly because I suspect I may have inadvertently cancelled it, while it was awaiting moderator approval. It's about manually compiling R-3.3.1 and using, not the standard system's (ver 1.0.5), but an alternate a bzip2 (v1.0.6) which is located in a non-standard

Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays

> Radford Neal > on Thu, 8 Sep 2016 17:11:18 -0400 writes: > Regarding Martin Maechler's proposal: > Arithmetic between length-1 arrays and longer non-arrays had > silently dropped the array attributes and recycled. This now gives > a warning

Re: [Rd] R (development) changes in arith, logic, relop with (0-extent) arrays

Thank you, Gabe and Bill, for taking up the discussion. > William Dunlap > on Thu, 8 Sep 2016 10:45:07 -0700 writes: > Prior to the mid-1990s, S did "length-0 OP length-n -> rep(NA, n)" and it > was changed > to "length-0 OP length-n -> length-0" to