Melt.data.frame () changes behavior when POSIXct columns are printed

The melting of the t.wide frame changes the output order of the time column (POSIXct class).

t.wide <- data.frame(product=letters[1:5], result=c(2, 4, 0, 0, 1), t1=as.POSIXct("2014-05-26") + seq(0, 10800, length.out=5), t2=as.POSIXct("2014-05-27") + seq(0, 10800, length.out=5), t3=as.POSIXct("2014-05-28") + seq(0, 10800, length.out=5)) library(reshape2) t.long <- melt(t.wide, measure.vars=c("t1", "t2", "t3"), value.name="time") t.long$time [1] 1401055200 1401057900 1401060600 1401063300 1401066000 1401141600 1401144300 [8] 1401147000 1401149700 1401152400 1401228000 1401230700 1401233400 1401236100 [15] 1401238800 attr(,"class") [1] "POSIXct" "POSIXt" 

It's strange if print() is called explicitly, the object prints as expected (timestamps, not their numeric representation).

 print(t.long$time) [1] "2014-05-26 00:00:00 CEST" "2014-05-26 00:45:00 CEST" "2014-05-26 01:30:00 CEST" [4] "2014-05-26 02:15:00 CEST" "2014-05-26 03:00:00 CEST" "2014-05-27 00:00:00 CEST" [7] "2014-05-27 00:45:00 CEST" "2014-05-27 01:30:00 CEST" "2014-05-27 02:15:00 CEST" [10] "2014-05-27 03:00:00 CEST" "2014-05-28 00:00:00 CEST" "2014-05-28 00:45:00 CEST" [13] "2014-05-28 01:30:00 CEST" "2014-05-28 02:15:00 CEST" "2014-05-28 03:00:00 CEST" 

Setting attributes to the same value as before the magical change in the way the object is printed.

 attributes(t.long$time) <- attributes(t.long$time) t.long$time [1] "2014-05-26 00:00:00 CEST" "2014-05-26 00:45:00 CEST" "2014-05-26 01:30:00 CEST" [4] "2014-05-26 02:15:00 CEST" "2014-05-26 03:00:00 CEST" "2014-05-27 00:00:00 CEST" [7] "2014-05-27 00:45:00 CEST" "2014-05-27 01:30:00 CEST" "2014-05-27 02:15:00 CEST" [10] "2014-05-27 03:00:00 CEST" "2014-05-28 00:00:00 CEST" "2014-05-28 00:45:00 CEST" [13] "2014-05-28 01:30:00 CEST" "2014-05-28 02:15:00 CEST" "2014-05-28 03:00:00 CEST" 

Can anyone explain this behavior?

+7
r reshape2 posixct
source share
1 answer

UPDATE:

I discovered this as Issue 50 in the git hasley / reshape2 repository .


UPDATE: FIXED

This issue has been fixed in the reshape2 development reshape2 .

Thanks @ kevin-ushey !


I believe that the reason is that after the change for some reason, R does not think that t.long$time has attributes. For some reason, the OBJECT flag (which indicates that the vector has attributes) in the SEXP header is not set for your vector. When you copy the attributes back, the OBJECT flag is set and the correct printing method is sent ...

 # No "OBJ" in SEXP header (the '[NAM(2),ATT]' part below) .Internal(inspect( t.long$time ) ) #@10359e548 14 REALSXP g0c6 [NAM(2),ATT] (len=15, tl=0) 1.40106e+09,... # Now we have "OBJ" in the SEXP header indicating attributes # So the print method for POSIXct get dispatched... attributes(t.long$time) <- attributes(t.long$time) .Internal(inspect( t.long$time ) ) #@1118d7f50 14 REALSXP g0c6 [OBJ,NAM(2),ATT] (len=15, tl=0) 1.40106e+09,... 

From R Internals ...

Actual startup is done by PrintValueEnv in the print.c file. If the printable has S4 bit, and sending S4 is enabled, show is called to call the printable. Otherwise, if the bit of the object is set (therefore, the object has the attribute "class" ), print is called to the sending methods: for objects without a class, the internal code print.default is called.

Check the difference between ..

 print.default(t.long$time) # [1] 1401058800 1401061500 1401064200 1401066900 1401069600 1401145200 1401147900 1401150600 1401153300 1401156000 1401231600 1401234300 #[13] 1401237000 1401239700 1401242400 #attr(,"class") #[1] "POSIXct" "POSIXt" print.POSIXct(t.long$time) # [1] "2014-05-26 00:00:00 BST" "2014-05-26 00:45:00 BST" "2014-05-26 01:30:00 BST" "2014-05-26 02:15:00 BST" "2014-05-26 03:00:00 BST" # [6] "2014-05-27 00:00:00 BST" "2014-05-27 00:45:00 BST" "2014-05-27 01:30:00 BST" "2014-05-27 02:15:00 BST" "2014-05-27 03:00:00 BST" #[11] "2014-05-28 00:00:00 BST" "2014-05-28 00:45:00 BST" "2014-05-28 01:30:00 BST" "2014-05-28 02:15:00 BST" "2014-05-28 03:00:00 BST" 

Now I can only guess, but maybe this is due to some internal code in reshape2 and is related to this warning ..

You should pay attention to the fact that if you copy attributes from one object to another, you can (un) set the "class" attribute, and therefore you also need to copy the object and S4 bits. For its automation there is a macro / function DUPLICATE_ATTRIB .

+6
source share

All Articles