Yeah, I was unclear about what I mean by "uneven vector lengths". I should say "uneven valid vectors" instead where "valid" refers to (1) a field containing a value that is not NA, for this specific case, and (2) a value that is compatible with the vector class assigned through colClasses etc., and therefore avoids the read.zoo error. I understand and agree that the error is clear. I have no issue with that. My issue is with the need to use read.table and then read.zoo shortly after (this seems inefficient).
I was simply pushing toward the idea of where this type of situation could be avoided for future users in where if there are uneven valid vectors that there would be a logical argument saying that it's okay to truncate to the shortest valid vector (in this case columns 1 and 2). My raw data consisted of a lot of uneven valid vectors. My expected thought of nulling out columns 3:5 would be that there would have no need for read.zoo to try to read in the bad data entry rows in columns 1:2 containing NA's that's already outside of the valid vector length. Anyway, this is probably trivial now considering that this problem is already solved haha, and also I don't mean to offend and criticize. I simply see an efficiency opportunity and an opportunity to create more robust source code. Why use read.table with read.zoo if you can just do it all with read.zoo? Do you not agree? -- View this message in context: http://r.789695.n4.nabble.com/uneven-vector-length-issue-with-read-zoo-tp4604287p4613975.html Sent from the R help mailing list archive at Nabble.com. ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.