similar to: NaN/NA and sprintf double format

ripley@stats.ox.ac.uk wrote: > > On Tue, 14 May 2002, Dirk Eddelbuettel wrote: > > > With a (late prerelease of) 1.5.0 on Windows, using sprintf on NaN > > yields garbage when the number of decimal is specified while it > > works fine for NA: > > > > > sprintf("%.2f", NA) > > [1] "0.00" > > I get that on Linux too, but

Full_Name: Oren Cheyette Version: 2.7.2 OS: Win XP Submission from: (NULL) (64.161.123.194) Enter the following at the R command prompt: > sprintf("A %S %S %S XYZ", 1, 1, 1); Note the erroneous capitalized %S instead of %s and the numeric inputs instead of strings. With strings there's no crash - R reports bad format specifications.

Hi guys. Check this out: > NaN +NA [1] NaN > NA + NaN [1] NA I thought "+" was commutative by definition. What's going on? > R.version _ platform powerpc-apple-darwin6.8 arch powerpc os darwin6.8 system powerpc, darwin6.8 status major 1 minor 9.0 year 2004 month 04 day 12 language R > (Both give NA under linux, so it looks

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]]

I have an issue using mle in versions of 32 bits. I am writing a package which I want to submit to the CRAN. When doing the check, there is an example that has an error running in the 32 bits version. The problem comes from the mle function, using it with a lower constrain. In 64 bits version it works fine but when I put it in the R 32 bits it fails. (same numbers, all equal!) The call is:

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]]

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

Hi, I want to recode all Inf and NaN values to NA, but I;m surprised to see the result of the following code. Could anybody enlighten me about this? > df <- data.frame(a=c(NA, NaN, Inf, 1:3)) > df[is.infinite(df) | is.nan(df)] <- NA > df a 1 NA 2 NaN 3 Inf 4 1 5 2 6 3 > Thanks! Cheers!! Albert-Jan

Hi, I want to recode all Inf and NaN values to NA, but I;m surprised to see the result of the following code. Could anybody enlighten me about this? > df <- data.frame(a=c(NA, NaN, Inf, 1:3)) > df[is.infinite(df) | is.nan(df)] <- NA > df a 1 NA 2 NaN 3 Inf 4 1 5 2 6 3 > Thanks! Cheers!! Albert-Jan

Hello, I notice in main/arithmetic.c, that NA and NaN are encoded differently(since every numeric NA comes from R_NaReal which is defined via ValueOfNA) . What is the benefit of treating these two differently? Why can't NA be a synonym for NaN? Thank you Saptarshi (R-2.9)

The help page for function identical says: 'identical' sees 'NaN' as different from 'as.double(NA)', but all 'NaN's are equal (and all 'NA' of the same type are equal). However, we have x <- NaN y <- as.double(NA) x # [1] NaN y # [1] NA identical(x,y) # [1] TRUE In my opinion, NaN and as.double(NA) should be distinguished as the

Extremes.Rd, that documents 'max' and 'pmax', has this in "Details" section, in the paragraph before the last. By definition the min/max of a numeric vector containing an NaN is NaN, except that the min/max of any vector containing an NA is NA even if it also contains an NaN. ------------------ >>>>> Michal Burda <michal.burda at centrum.cz>

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,

Hi all, I ran into a problem in some of my code that could be traced back to 'mean' sometimes returning NA and sometimes NaN, depending on the value of na.rm: > mean(c()) [1] NA > mean(c(NA),na.rm=T) [1] NaN However, I don't understand the reasoning behind this and would appreciate and explanation. I understand that the mean of an empty vector is not definied, but I

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

Hi all.. I'm very new R, and i'm analyzing microarray data using Bioconductor.. Recently i was given microarray data to analyze. The problem is whenever i run MAS5 presence calls algorithm, it throws an error saying NA/NaN/Inf in foreign function. How do i remove such NA/NaN/Inf's ?? I tried na.omit(dataframe) but stil problem exists. dimension of matrix (data) is 35556 7. >

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

"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

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?: >

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