similar to: as.Date(Inf) displays as 'NA' but is actually 'Inf'

Displaying 20 results from an estimated 20000 matches similar to: "as.Date(Inf) displays as 'NA' but is actually 'Inf'"

2019 Mar 06
2
as.Date(Inf) displays as 'NA' but is actually 'Inf'
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) see an NA, we then use is.na(). If we see Inf displayed, we then use is.infinite(). With as.Date() this breaks down. I'm not arguing that as.Date(Inf) should be coerced to NA. I'm arguing that as.Date(Inf) should be *visually* displayed as Inf (i.e. the
2019 Mar 05
0
as.Date(Inf) displays as 'NA' but is actually 'Inf'
Richard, Well others may chime in here, but from a mathematical point of view, the concept of "infinite days from right now" is well-defined, so it maybe a "valid" date in that sense, but what day and month it will be (year will be Inf) are indeterminate/not well defined. Those are rightfully, NA, it seems? I mean you could disallow dates to take Inf at all, ever. I don't
2019 Mar 06
0
as.Date(Inf) displays as 'NA' but is actually 'Inf'
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) see an NA, we then use is.na(). If we > see Inf displayed, we then use is.infinite(). With as.Date() this breaks > down. > > I'm not arguing that
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)
2018 May 10
2
readLines() behaves differently for gzfile connection
When I read a .gz file with readLines() in 3.4.3, it returns text (and a warning). In 3.5.0, it gives a warning, but no text. Is this expected behavior or a bug? 3.4.3: > source_file = "1k_annotation.gz" > readfile_con <- gzfile(source_file, "r") > readLines(readfile_con, n = 5) [1] "#chr\tpos\tref\talt\t <truncated output here> Warning message: In
2018 Jul 26
2
Random behavior of mclapply
Hi, I wondered about the behavior described in the following stackoverflow question: https://stackoverflow.com/questions/20674538/mclapply-returns-null-randomly More specifically, I would like to know if you ever considered the suggestion made in the comments of the first answer, namely to somehow warn the user if one of the processes has been killed by the out-of-memory killer ? I am always
2018 May 10
1
readLines() behaves differently for gzfile connection
You bet - it's available on github at https://github.com/UW-GAC/wgsaparsr/blob/master/tests/testthat/1k_annotation.gz -Ben On Thu, May 10, 2018 at 4:17 PM, Michael Lawrence <lawrence.michael at gene.com > wrote: > Would it be possible to get that file or a representative subset of it > somewhere so that I can reproduce this? > > Thanks, > Michael > > On Thu, May
2018 Jun 14
2
makeCluster Stall on 32-bit Windows
Good day, I'm trying the example cl <- makeCluster(2, type = "SOCK") from the makeCluster documentation and the R command prompt never returns. I am using a 32-bit Windows 10 computer. The problem doesn't happen on another 64-bit Windows 10 computer but does happen on another 32-bit Windows 7 computer. Can anyone reproduce it? Are there any other options that can be passed to
2018 May 02
7
download.file does not process gz files correctly (truncates them?)
Dear all, I've noticed by trying to download gz files from here : https://www.ncbi.nlm.nih.gov/geo/query/acc.cgi?acc=GSM907811 At the bottom one can download GSM907811.CEL.gz . If I download this manually and try oligo::read.celfiles("GSM907811.CEL.gz") everything works fine. (oligo is a bioConductor package) However, if I download using download.file("
2018 May 09
3
NAs produced by integer overflow, but only some time ...
I have problem with integer overflow that I cannot understand. I have a character vector curr.lemmas with the following properties: length(curr.lemmas) # 61224 length(unique(curr.lemmas)) # 2652 That vector is the input to the following function: yules.k1 <- function(input) { m1 <- length(input); temp <- table(table(input)) m2 <- sum("*"(temp,
2017 Jun 01
2
[FORGED] Re: Question on function "scatterplot3d"
On 01/06/17 13:17, Ismail SEZEN wrote: > >> On 1 Jun 2017, at 03:41, li li <hannah.hlx at gmail.com> wrote: >> >> Hi all, >> I have a question with regard to making plots using function >> "scatterplot3d". >> Please see the example below. It looks like, for y axis, the tickmark text >> was cutoff. >> The number "10"
2017 Jun 01
0
Question on function "scatterplot3d"
> On 1 Jun 2017, at 03:41, li li <hannah.hlx at gmail.com> wrote: > > Hi all, > I have a question with regard to making plots using function > "scatterplot3d". > Please see the example below. It looks like, for y axis, the tickmark text > was cutoff. > The number "10" does not show up completely. I tried to work with par(mpg). > It does not
2017 Jun 01
2
Question on function "scatterplot3d"
Hi all, I have a question with regard to making plots using function "scatterplot3d". Please see the example below. It looks like, for y axis, the tickmark text was cutoff. The number "10" does not show up completely. I tried to work with par(mpg). It does not seem to work. Hope to get some advice here. Thanks much! Hanna C <- runif(30) B <- rep(1:3, each=10) A
2018 Jun 08
2
Date class shows Inf as NA; this confuses the use of is.na()
In the following example, the date class shows Inf as NA > as_date(Inf, origin = '1970-01-01') [1] NA This is misleading as is.na() reports incorrectly > is.na(as_date(Inf, origin = '1970-01-01')) [1] FALSE The correct approach here would probably to have an Inf (and -Inf) *displayed* rather than NA. [[alternative HTML version deleted]]
2018 May 09
0
NAs produced by integer overflow, but only some time ...
a) Numeric values may be either integers (signed 32 bit) or double precision (53 bit mantissa). b) Double precision constants are numeric with no decoration (e.g. 61224). Integer constants have an L (e.g. 61224L). c) 61224*61224 > 2^31-1 so that answer cannot fit into an integer. d) Exponentiation is a floating point operation so the result of 61224L^2L is a floating point answer that CAN
2017 Sep 17
2
R-devel r73293 and the testthat package
Hello, Windows R-devel no longer lets me use testthat even though the CRAN checks are pretty much clean. I have copied my session output below. Will R Under development (unstable) (2017-09-16 r73293) -- "Unsuffered Consequences" Copyright (C) 2017 The R Foundation for Statistical Computing Platform: x86_64-w64-mingw32/x64 (64-bit) R is free software and comes with ABSOLUTELY NO
2018 Jun 22
1
Bug in as.Date or strptime?
Hello, This just came up in SO, sessionInfo() at the end. https://stackoverflow.com/questions/50988018/seeking-explanation-for-as-date-function-in-r?noredirect=1#comment88971055_50988018 # example 1 # not even the month is right as.Date(x = 1, format = '%j', origin= '2015-01-01') #[1] "2018-07-21" # example 2a # nonsense output as.Date(x = 1, origin=
2010 May 13
1
results of pnorm as either NaN or Inf
I stumbled across this and I am wondering if this is unexpected behavior or if I am missing something. > pnorm(-1.0e+307, log.p=TRUE) [1] -Inf > pnorm(-1.0e+308, log.p=TRUE) [1] NaN Warning message: In pnorm(q, mean, sd, lower.tail, log.p) : NaNs produced > pnorm(-1.0e+309, log.p=TRUE) [1] -Inf I don't know C and am not that skilled with R, so it would be hard for me to look into
2018 Jun 11
2
Date class shows Inf as NA; this confuses the use of is.na()
Emil et al., On Mon, Jun 11, 2018 at 1:08 AM, Emil Bode <emil.bode at dans.knaw.nl> wrote: > I don't think there's much wrong with is.na(as_date(Inf, > origin='1970-01-01'))==FALSE, as there still is some "non-NA-ness" about > the value (as difftime shows), but that the output when printing is > confusing. The way cat is treating it is clearer: it
2015 Oct 21
1
Confusing print method for Inf dates
x <- as.Date(Inf, origin = "1970-01-01") x #> [1] NA str(x) #> Date[1:1], format: NA unclass(x) #> [1] Inf It's not clear what the correct behaviour is. The documentation for ?Date has: "It is intended that the date should be an integer,", which suggests that -Inf and Inf are not valid dates. But if that's true the behaviour for max.Date() needs some