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 g
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
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 doubl
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 take
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
> > on Thu, 8 Sep 2016 1
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 thi
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,
> but I thought,
> tan(
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 cases - that is why
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
Not
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 message:
> In 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 close
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
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
el
> 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:
> Tha
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 altern
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
> 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 and will signal an error
17 matches
Mail list logo
