Wrong length of POSIXt vectors (PR#10507)

On 12/13/2007 1:59 PM, Tony Plate wrote:

Duncan Murdoch wrote:

On 12/11/2007 6:20 AM, simecek at gmail.com wrote:

Full_Name: Petr Simecek
Version: 2.5.1, 2.6.1
OS: Windows XP
Submission from: (NULL) (195.113.231.2)


Several times I have experienced that a length of a POSIXt vector 
has not been
computed right.

Example:

tv<-structure(list(sec = c(50, 0, 55, 12, 2, 0, 37, NA, 17, 3, 31
), min = c(1L, 10L, 11L, 15L, 16L, 18L, 18L, NA, 20L, 22L, 22L
), hour = c(12L, 12L, 12L, 12L, 12L, 12L, 12L, NA, 12L, 12L, 12L), 
mday = c(13L, 13L, 13L, 13L, 13L, 13L, 13L, NA, 13L, 13L, 13L), mon 
= c(5L, 5L, 5L, 5L, 5L, 5L, 5L, NA, 5L, 5L, 5L), year = c(105L, 
105L, 105L, 105L, 105L, 105L, 105L, NA, 105L, 105L, 105L), wday = 
c(1L, 1L, 1L, 1L, 1L, 1L, 1L, NA, 1L, 1L, 1L), yday = c(163L, 163L, 
163L, 163L, 163L, 163L, 163L, NA, 163L, 163L, 163L), isdst = c(1L, 
1L, 1L, 1L, 1L, 1L, 1L, -1L, 1L, 1L, 1L)), .Names = c("sec", "min", 
"hour", "mday", "mon", "year", "wday", "yday", "isdst"
), class = c("POSIXt", "POSIXlt"))

print(tv)
# print 11 time points (right)

length(tv)
# returns 9 (wrong)

tv is a list of length 9.  The answer is right, your expectation is 
wrong.

I have tried that on several computers with/without switching to 
English
locales, i.e. Sys.setlocale("LC_TIME", "en"). I have searched a 
help pages but I
cannot imagine how that could be OK.

See this in ?POSIXt:

Class '"POSIXlt"' is a named list of vectors...

You could define your own length measurement as

length.POSIXlt <- function(x) length(x$sec)

and you'll get the answer you expect, but be aware that length.XXX 
methods are quite rare, and you may surprise some of your users.

On the other hand, isn't the fact that length() currently always 
returns 9 for POSIXlt objects likely to be a surprise to many users 
of POSIXlt?

The back of "The New S Language" says "Easy-to-use facilities allow 
you to organize, store and retrieve all sorts of data. ... S 
functions and data organization make applications easy to write."

Now, POSIXlt has methods for c() and vector subsetting "[" (and many 
other vector-manipulation methods - see methods(class="POSIXlt")).  
Hence, from the point of view of intending to supply "easy-to-use 
facilities ... [for] all sorts of data", isn't it a little 
incongruous that length() is not also provided -- as 3 functions (any 
others?) comprise a core set of vector-manipulation functions?

Would it make sense to have an informal prescription (e.g., in 
R-exts) that a class that implements a vector-like object and 
provides at least of one of functions 'c', '[' and 'length' should 
provide all three?  It would also be easy to describe a test-suite 
that should be included in the 'test' directory of a package 
implementing such a class, that had some tests of the basic 
vector-manipulation functionality, such as:

 > # at this point, x0, x1, x3, & x10 should exist, as vectors of the
 > # class being tested, of length 0, 1, 3, and 10, and they should
 > # contain no duplicate elements
 > length(x0)

[1] 1

 > length(c(x0, x1))

[1] 2

 > length(c(x1,x10))

[1] 11

 > all(x3 == x3[seq(len=length(x3))])

[1] TRUE

 > all(x3 == c(x3[1], x3[2], x3[3]))

[1] TRUE

 > length(c(x3[2], x10[5:7]))

[1] 4

 >

It would also be possible to describe a larger set of vector 
manipulation functions that should be implemented together, including 
e.g., 'rep', 'unique', 'duplicated', '==', 'sort', '[<-', 'is.na', 
head, tail ... (many of which are provided for POSIXlt).

Or is there some good reason that length() cannot be provided (while 
'c' and '[' can) for some vector-like classes such as "POSIXlt"?

What you say sounds good in general, but the devil is in the details. 
Changing the meaning of length(x) for some objects has fairly 
widespread effects.  Are they all positive?  I don't know.

Adding a prescription like the one you suggest would be good if it's 
easy to implement, but bad if it's already widely violated.  How many 
base or CRAN or Bioconductor packages violate it currently?   Do the 
ones that provide all 3 methods do so in a consistent way, i.e. does 
"length(x)" mean the same thing in all of them?

I agree that the current state is less than perfect, but making it 
better would really be a lot of work.  I suspect there are better ways 
to spend my time, so I'm not going to volunteer to do it.  I'm not 
even going to invite someone else to do it, or offer to review your 
work if you volunteer.  I think this falls into the class of "next 
time we write a language, let's handle this better" problems.

Duncan Murdoch