Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

Gabe, > Also, I would expect the year 1e50 and the "year" Inf to be functionally > equivalent in meaning (and largely meaningless) in context. indeed. thanks, Greg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

Greg, I see what you mean, but on the other hand, that's not how we think about real numbers working either, and doubles have that behavior generally. It might be possible to put checks in (with a potentially non-trivial overhead cost) to disallow that kind of thing, but again R (and everyone

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

Martin, et al., > I think we should allow 'year' to be "double" instead, and so it > could also be +Inf or -Inf and we'd nicely cover > the conversions from and to 'numeric' -- which is really used > internally for dates and date-times in POSIXct. storing years as a double makes me worry

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

On Tue, Jun 12, 2018 at 6:28 PM, Martin Maechler wrote: > > I think we should allow 'year' to be "double" instead, and so it > could also be +Inf or -Inf and we'd nicely cover > the conversions from and to 'numeric' -- which is really used > internally for dates and date-times in POSIXct. > >

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

> Emil Bode > on Tue, 12 Jun 2018 12:00:42 + writes: > I agree that calling it invalid is a bit confusing, but I’m not sure what the > wording should be, as the problem is that the conversion to POSIXlt is > failing. > The best solution would be to extend the whole

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

I agree that calling it invalid is a bit confusing, but I’m not sure what the wording should be, as the problem is that the conversion to POSIXlt is failing. The best solution would be to extend the whole POSIXlt-class, but that’s too much work. I’ve done some experiments, and it also seems that

Re: [Rd] 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 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

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

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 does print Inf. So would this be a

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

On Mon, Jun 11, 2018 at 11:12 AM, Martin Maechler < maech...@stat.math.ethz.ch> wrote: > > and a Date vector *is* atomic .. (so I'm confused about what > that issue is .. but read one. > Indeed. I tend to exclude everything with a formal class from "atomic" (eg factors et al) because they do

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

> Joris Meys > on Sat, 9 Jun 2018 13:45:21 +0200 writes: > And now I've seen I copied the wrong part of ?is.na >> The default method for is.na applied to an atomic vector >> returns a > logical vector of the same length as its argument x, > containing TRUE for

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

And now I've seen I copied the wrong part of ?is.na > The default method for is.na applied to an atomic vector returns a logical vector of the same length as its argument x, containing TRUE for those elements marked NA or, for numeric or complex vectors, NaN, and FALSE otherwise. Key point being

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

Hi Werner, on ?is.na it says: > The default method for anyNA handles atomic vectors without a class and NULL. I hear you, and it is confusing to say the least. Looking deeper, the culprit seems to be in the conversion of a Date to POSIXlt prior to the formatting: > x <- as.Date(Inf,origin =

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

Indeed. as_date is from lubridate, but the same holds for as.Date. The output and it's interpretation should be consistent, otherwise it leads to confusion when programming. I understand that the difference exists after asking a question on Stack Overflow:

Re: [Rd] Date class shows Inf as NA; this confuses the use of is.na()

> as_date Error: object 'as_date' not found Must be from some not-named package... But don't confuse the format of an object when printed with its underlying value: > as.Date(Inf,origin = '1970-01-01') [1] NA > str(as.Date(Inf,origin = '1970-01-01')) Date[1:1], format: NA >

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