similar to: NA and NaN in function identical

Displaying 20 results from an estimated 10000 matches similar to: "NA and NaN in function identical"

2009 Apr 30
2
NA_real_ <op> NaN -> NA or NaN, should we care?
On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in particular) with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when adding NA and NaN: > NA_real_ + NaN [1] NaN > NaN + NA_real_ [1] NA If I compile src/main/arithmetic.c without optimization (just -g) then both of those return NA. On Windows, using a precompiled R 2.8.1 from CRAN I get NA for
2020 Jan 01
2
New R function is.nana = is.na & !is.nan
Hello R-devel, Best wishes in the new year. I am writing to kindly request new R function so NA_real_ can be more easily detected. Currently if one wants to test for NA_real_ (but not NaN) then extra work has to be done: `is.na(x) & !is.nan(x)` Required functionality is already at C level so to address my request there is not that much to do. Kevin Ushey made a nice summary of current R C api
2020 Jan 02
1
New R function is.nana = is.na & !is.nan
"nana" is meant to express "NA, really NA". Your suggestion sounds good. On Thu 2 Jan, 2020, 3:38 AM Pages, Herve, <hpages at fredhutch.org> wrote: > Happy New Year everybody! > > The name (is.nana) doesn't make much sense to me. Can you explain it? > > One alternative would be to add an extra argument (e.g. 'strict') to > is.na(). FALSE by
2023 Apr 14
1
Possible inconsistency between `as.complex(NA_real_)` and the docs
Hi all, Surprisingly (at least to me), `as.complex(NA_real_)` results in `complex(real = NA_real_, imaginary = 0)` rather than `NA_complex_`. It seems to me that this goes against the docs of `as.complex()`, which say this in the Details section: "Up to R versions 3.2.x, all forms of NA and NaN were coerced to a complex NA, i.e., the NA_complex_ constant, for which both the real and
2010 Mar 31
2
Should as.complex(NaN) -> NA?
I'm having trouble grokking complex NaN's. This first set examples using complex(re=NaN,im=NaN) give what I expect > Re(complex(re=NaN, im=NaN)) [1] NaN > Im(complex(re=NaN, im=NaN)) [1] NaN > Arg(complex(re=NaN, im=NaN)) [1] NaN > Mod(complex(re=NaN, im=NaN)) [1] NaN > abs(complex(re=NaN, im=NaN)) [1] NaN and so do the following > Re(complex(re=1,
2016 May 10
1
complex NA's match(), etc: not back-compatible change proposal
This is an RFC / announcement related to the 2nd part of PR#16885 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16885 about complex NA's. The (somewhat rare) incompatibility in R's 3.3.0 match() behavior for the case of complex numbers with NA & NaN's {which has been fixed for R 3.3.0 patched in the mean time} triggered some more comprehensive "research". I
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,
2020 Aug 31
1
make check fails due to NA / NaN mismatch
Thank you for the introduction to these recent changes, Martin. I think this was the second time I ran "make check" on that platform (Raspberry Pi 32-bit), and the first time (some months ago) it worked fine. So, that makes it kind of "suddenly", although I must say that my use of "make check" is very irregular. I compared code before and after the split you are
2009 Dec 15
3
RFC: lchoose() vs lfactorial() etc
lgamma(x) and lfactorial(x) are defined to return ln|Gamma(x)| {= log(abs(gamma(x)))} or ln|Gamma(x+1)| respectively. Unfortunately, we haven't chosen the analogous definition for lchoose(). So, currently > lchoose(1/2, 1:10) [1] -0.6931472 -2.0794415 NaN -3.2425924 NaN -3.8869494 [7] NaN -4.3357508 NaN -4.6805913 Warning message: In
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.
2023 Nov 08
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
So, to summarize, the open questions are: (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) instead of NA_complex_? (2) Should the first argument in c(NA, x) and c(NA_integer_, x), where typeof(x) == "complex", be promoted to complex(r=NA_real_, i=0) instead of NA_complex_? My opinions: (1) No. The imaginary part of the
2023 Nov 09
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
>>>>> Mikael Jagan >>>>> on Wed, 8 Nov 2023 11:13:18 -0500 writes: > So, to summarize, the open questions are: > (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0) > instead of NA_complex_? > (2) Should the first argument in c(NA, x) and c(NA_integer_, x), > where typeof(x) == "complex", be promoted
2023 Nov 06
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
>>>>> Michael Chirico >>>>> on Sun, 5 Nov 2023 09:41:42 -0800 writes: > This is another follow-up to the thread from September > "Recent changes to as.complex(NA_real_)". > A test in data.table was broken by the changes for NA > coercion to complex; the breakage essentially comes from > c(NA, 0+1i) > # vs
2019 Mar 06
1
as.Date(Inf) displays as 'NA' but is actually 'Inf'
>>>>> Gabriel Becker >>>>> on Tue, 5 Mar 2019 22:01:37 -0800 writes: > On Tue, Mar 5, 2019 at 9:54 PM Richard White <w at rwhite.no> wrote: >> Hi Gabriel, >> >> The point is that it *visually* displays as NA, but is.na() still >> responds as FALSE. >> >> When I (and I am sure many people)
2023 Nov 07
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
Thanks Martin. My hang-up was not on what the outcome of as.complex(NA) should be, but rather, how I should read code like c(x, y) generally. Till now, I have thought of it like 'c(x, y)' is c(as(x, typeof(y)), y)` when "type(y) > type(x)". Basically in my mind, "coercion" in R <-> as.<newtype>(.) (or coerceVector() in C). So I tracked down the source
2012 Jul 31
3
Help with NaN when 0 divided by 0
Hi All, I have some data where I am doing fairly simple calculations, nothing more than adding, subtracting, multiplying and dividing. I’m running into a problem when I divide one variable by another and when they’re both 0 I get NaN. I realize that if you divide a non-zero by 0 then you get Inf, which is, of course, correct. But in my case I never get Inf, just NaN because of the structure
2011 Sep 27
3
remove NaN from element in a vector in a list
Hello, What is the best way to turn a matrix into a list removing NaN's? I'm new to R... Start: > mt = matrix(c(1,4,NaN,5,3,6),2,3) > mt [,1] [,2] [,3] [1,] 1 NaN 3 [2,] 4 5 6 Desired result: > lst [[1]] [1] 1 3 [[2]] [1] 4 5 6 Thanks! Ben [[alternative HTML version deleted]]
2003 Oct 24
5
how to remove NaN columns ?
How can I remove columns with NaN entries ? Here is my simple example: > data <- read.csv("test.csv") > xdata <- data[3:length(data)] > xs <- lapply(xdata, function(x){(x - mean(x))/sqrt(var(x))}) > x <- data.frame(xs) > x C D E F 1 -0.7071068 NaN -0.7071068 -0.7071068 2 0.7071068 NaN 0.7071068 0.7071068
2017 Jan 11
2
R 'base' returning 0 as sum of NAs
Dear R Team The following line returns 0 (zero) as answer: sum(c(NA_real_, NA_real_, NA_real_, NA_real_), na.rm = TRUE) One would, however, have expected it to return 'NaN', as is the case with function 'mean': > mean(c(NA_real_, NA_real_, NA_real_, NA_real_), na.rm = TRUE) [1] NaN The problem in other words: I have a vector filled with missing numbers. I run the
2008 Mar 26
5
S4 slot with NA default
Hi How do I specify an S4 class with a slot that is potentially numeric, but NA by default? I want the slot to be NA until I calculate its value (an expensive operation, not needed for all applications). When its value is known, I will create a new object with the correct value inserted in the slot. I want "NA" to signify "not known". My attempt fails because