Displaying 20 results from an estimated 10000 matches similar to: "max and pmax of NA and NaN"
2018 Jan 15
1
max and pmax of NA and NaN
Dear R users,
is the following OK?
> max(NA, NaN)
[1] NA
> max(NaN, NA)
[1] NA
> pmax(NaN, NA)
[1] NA
> pmax(NA, NaN)
[1] NaN
...or is it a bug? Documentation says that NA has a higher priority over
NaN.
Best regards, Michal Burda
[[alternative HTML version deleted]]
2016 Aug 15
1
table(exclude = NULL) always includes NA
>>>>> Martin Maechler <maechler at stat.math.ethz.ch>
>>>>> on Mon, 15 Aug 2016 11:07:43 +0200 writes:
>>>>> Suharto Anggono Suharto Anggono <suharto_anggono at yahoo.com>
>>>>> on Sun, 14 Aug 2016 03:42:08 +0000 writes:
>> useNA <- if (missing(useNA) && !missing(exclude) && !(NA %in%
2017 Apr 01
1
complex NA's match(), etc: not back-compatible change proposal
I am raising this again.
With
z <- complex(real = c(0,NaN,NaN), imaginary = c(NA,NA,0)) ,
results of
sapply(z, match, table = z)
and
match(z, z)
are different in R 3.4.0 alpha. I think they should be the same.
I suggest changing 'cequal' in unique.c such that a complex number that has both NA and NaN matches NA and doesn't match NaN, as such complex number is printed as NA.
2016 Aug 14
2
table(exclude = NULL) always includes NA
useNA <- if (missing(useNA) && !missing(exclude) && !(NA %in% exclude)) "ifany"
An example where it change 'table' result for non-factor input, from https://stat.ethz.ch/pipermail/r-help/2005-April/069053.html :
x <- c(1,2,3,3,NA)
table(as.integer(x), exclude=NaN)
I bring the example up, in case that the change in result is not intended.
2016 Aug 17
1
table(exclude = NULL) always includes NA
The quirk as in table(1:3, exclude = 1, useNA = "ifany") is actually somewhat documented, and still in R devel r71104. In R help on 'table', in "Details" section:
It is best to supply factors rather than rely on coercion. In particular, ?exclude? will be used in coercion to a factor, and so values (not levels) which appear in ?exclude? before coercion will be mapped to
2016 Sep 10
1
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
a[a0 %in% c(exclude,NA)] <- NA .
So, it should be
is.na(a) <- match(a0, c(exclude,NA),
2016 May 28
1
complex NA's match(), etc: not back-compatible change proposal
On 'factor', I meant the case where 'levels' is not specified, where 'unique' is called.
> factor(c(complex(real=NaN), complex(imaginary=NaN)))
[1] NaN+0i <NA>
Levels: NaN+0i
Look at <NA> in the result above. Yes, it happens in earlier versions of R, too.
On matching both NA and NaN, another consequence is that length(unique(.)) may depend on order.
2006 Jul 11
2
0* log(0) should be zero but NaN
Dear R-users
>prob <- c(0.5,0.4,0.3,0.1,0.0)
>cal <- prob * log(prob,base=2)
>cal
[1] -0.5000000 -0.5287712 -0.5210897 -0.3321928 NaN
Is there any way to change NaN to zero ?
I did come up with this by applying Ripley's relpy to my previous question
cal <-prob*log(pmax(prob,0.00000001),base=2)
Any suggestion ?
Thank you
Taka
2017 Nov 04
1
ans[nas] <- NA in 'ifelse' (was: ifelse() woes ... can we agree on a ifelse2() ?)
Removal of
ans[nas] <- NA
from the code of function 'ifelse' in R is not committed (yet). Why?
--------------------------------------------
On Mon, 28/11/16, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
Subject: Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?
Cc: R-devel at r-project.org, maechler at stat.math.ethz.ch
Date: Monday, 28 November, 2016, 10:00
2016 Sep 02
2
Coercion of 'exclude' in function 'factor' (was 'droplevels' inappropriate change)
I am basically fine with the change.
How about using just the following?
if(!is.character(exclude))
exclude <- as.vector(exclude, typeof(x)) # may result in NA
x <- as.character(x)
It looks simpler and is, more or less, equivalent.
In factor.Rd, in description of argument 'exclude', "(when \code{x} is a \code{factor} already)" can be removed.
A larger
2016 May 13
1
complex NA's match(), etc: not back-compatible change proposal
That, for example, complex(real=NaN) and complex(imaginary=NaN) are regarded as equal makes it possible that length(unique(as.character(x))) > length(unique(x)) (current code of function 'factor' doesn't expect it). Yes, an argument for the behavior is that NA and NaN are of one kind.
On my system, using 32-bit R for Windows from binary from CRAN, the result of sapply(z, match,
2012 Oct 30
4
There is pmin and pmax each taking na.rm, how about psum?
Hi,
Please consider the following :
x = c(1,3,NA,5)
y = c(2,NA,4,1)
min(x,y,na.rm=TRUE) # ok
[1] 1
max(x,y,na.rm=TRUE) # ok
[1] 5
sum(x,y,na.rm=TRUE) # ok
[1] 16
pmin(x,y,na.rm=TRUE) # ok
[1] 1 3 4 1
pmax(x,y,na.rm=TRUE) # ok
[1] 2 3 4 5
psum(x,y,na.rm=TRUE)
[1] 3 3 4 6 # expected result
Error: could not find function "psum" # actual result
2016 Aug 11
2
table(exclude = NULL) always includes NA
I stand corrected. The part "If set to 'NULL', it implies 'useNA="always"'." is even in the documentation in R 2.8.0. It was my fault not to check carefully.
I wonder, why "always" was chosen for 'useNA' for exclude = NULL.
Why exclude = NULL is so special? What about another 'exclude' of length zero, like character(0) (not c(),
2017 Feb 01
1
RFC: tapply(*, ..., init.value = NA)
On 'aggregate data.frame', the URL should be https://stat.ethz.ch/pipermail/r-help/2016-May/438631.html .
vector(typeof(ans))
(or vector(storage.mode(ans)))
has length zero and can be used to initialize array.
Instead of
if(missing(default)) ,
if(identical(default, NA))
could be used. The documentation could then say, for example: "If default = NA (the default), NA of appropriate
2018 Jul 02
2
base::mean not consistent about NA/NaN
Hi,
base::mean is not consistent in terms of handling NA/NaN.
Mean should not depend on order of its arguments while currently it is.
mean(c(NA, NaN))
#[1] NA
mean(c(NaN, NA))
#[1] NaN
I created issue so in case of no replies here status of it can be looked up
at:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441
Best,
Jan
[[alternative HTML version deleted]]
2017 Apr 01
1
mean(x) != mean(rev(x)) different with x <- c(NA, NaN) for some builds
On Fri, Mar 31, 2017 at 10:14 PM, Prof Brian Ripley
<ripley at stats.ox.ac.uk> wrote:
> From ?NA
>
> Numerical computations using ?NA? will normally result in ?NA?: a
> possible exception is where ?NaN? is also involved, in which case
> either might result.
>
> and ?NaN
>
> Computations involving ?NaN? will return ?NaN? or perhaps ?NA?:
>
2016 Sep 26
2
Undocumented 'use.names' argument to c()
By "an argument named 'use.names' is included for concatenation", I meant something like this, that someone might try.
> c(as.Date("2016-01-01"), use.names=FALSE)
use.names
"2016-01-01" "1970-01-01"
See, 'use.names' is in the output. That's precisely because 'c.Date' doesn't have 'use.names', so
2018 Jul 18
1
base::mean not consistent about NA/NaN
Yes, the performance overhead of fixing this at R level would be too
large and it would complicate the code significantly. The result of
binary operations involving NA and NaN is hardware dependent (the
propagation of NaN payload) - on some hardware, it actually works the
way we would like - NA is returned - but on some hardware you get NaN or
sometimes NA and sometimes NaN. Also there are C
2018 Jul 02
2
base::mean not consistent about NA/NaN
And for a starker example of this (documented) inconsistency,
arithmetic addition is not commutative:
> NA + NaN
[1] NA
> NaN + NA
[1] NaN
On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
> On 02/07/2018 11:25 AM, Jan Gorecki wrote:
>> Hi,
>> base::mean is not consistent in terms of handling NA/NaN.
>> Mean should not
2019 May 30
2
stopifnot
Here is a patch to function 'stopifnot' that adds 'evaluated' argument and makes 'exprs' argument in 'stopifnot' like 'exprs' argument in 'withAutoprint'.
--- stop.R 2019-05-30 14:01:15.282197286 +0000
+++ stop_new.R 2019-05-30 14:01:51.372187466 +0000
@@ -31,7 +31,7 @@
.Internal(stop(call., .makeMessage(..., domain = domain)))
}