unlist strips date class

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

unlist strips date class

Kenny Bell-2
Is this a bug?

> unlist(list(as.Date("2015-01-01")))
[1] 16436

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: unlist strips date class

Dirk Eddelbuettel

On 2 December 2016 at 10:45, Kenny Bell wrote:
| Is this a bug?
|
| > unlist(list(as.Date("2015-01-01")))
| [1] 16436

Not really, it is documented.

S3 classes operate via an attribute tag, and attributes get dropped by
certain base functions. I must have hit something like the following about a
thousand times by now:

R> for (i in as.Date("2015-01-01")+ 0:2) print(i)
[1] 16436
[1] 16437
[1] 16438
R>

Live and learn.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: unlist strips date class

Hervé Pagès-2
In reply to this post by Kenny Bell-2
Hi,

On 12/02/2016 10:45 AM, Kenny Bell wrote:
> Is this a bug?
>
>> unlist(list(as.Date("2015-01-01")))
> [1] 16436

Good question.

More generally one might reasonably expect 'unlist(x)' to be equivalent
to 'do.call(c, x)' on a list 'x' where all the list elements are atomic
vectors:

   x <- list(1:3, letters[1:2])
   unlist(x)
   # [1] "1" "2" "3" "a" "b"
   do.call(c, x)
   # [1] "1" "2" "3" "a" "b"

However, if the list contains dates:

   x <- list(as.Date("2015-01-01") + 0:2, as.Date("2016-12-02"))
   unlist(x)
   # [1] 16436 16437 16438 17137
   do.call(c, x)
   # [1] "2015-01-01" "2015-01-02" "2015-01-03" "2016-12-02"

then 'unlist(x)' drops the attributes and 'do.call(c, x)' does not.

And if the list contains factors:

   x <- list(factor("Z"), factor(c("a", "Z", "b")))
   unlist(x)
   # [1] Z a Z b
   # Levels: Z a b
   do.call(c, x)
   # [1] 1 1 3 2

then it's the other way around. Also note that the fact that the first
2 numbers in the result of 'do.call(c, x)' are the same is
confusing/misleading. Hard to see how this result could be useful
to anybody.

These inconsistencies might well be documented but hopefully they can
be addressed.

Cheers,
H.

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: unlist strips date class

Peter Dalgaard-2

On 02 Dec 2016, at 23:13 , Hervé Pagès <[hidden email]> wrote:

> More generally one might reasonably expect 'unlist(x)' to be equivalent
> to 'do.call(c, x)' on a list 'x' where all the list elements are atomic
> vectors:

Well, both are generic, and e.g. there is no "Date" method for unlist(), but there is for c(). It is not clear that the two should be kept in lockstep and there is certainly no mechanism to enforce that.

--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: unlist strips date class

Hervé Pagès-2
On 12/05/2016 01:05 AM, peter dalgaard wrote:
>
> On 02 Dec 2016, at 23:13 , Hervé Pagès <[hidden email]> wrote:
>
>> More generally one might reasonably expect 'unlist(x)' to be equivalent
>> to 'do.call(c, x)' on a list 'x' where all the list elements are atomic
>> vectors:
>
> Well, both are generic, and e.g. there is no "Date" method for unlist(), but there is for c(). It is not clear that the two should be kept in lockstep and there is certainly no mechanism to enforce that.

If unlist() was based on c(), or c() was based on unlist(), or
unlist() and c() were sharing more code internally, then they would
naturally be kept in lockstep and you wouldn't need any mechanism to
enforce that.

Note that the arguments of the default S3 method for c() are:

   c(..., recursive = FALSE, use.names = TRUE)

i.e. exactly the same as unlist() (except for the default value).
This suggests that implementing one on top of the other is kind of a
natural thing to do.

H.

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel