> 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
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
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
> 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
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
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
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
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)
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
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
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(
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
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
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
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
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
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
17 matches
Mail list logo
