great! Indeed, ideally I would prefer to find some 1-step solution, but such elegant thing seems to be impossible for this case, while your code does the job just as I needed. thanks a lot!
–
Vasily AMar 3 '13 at 6:40

+1 nice! even it is a little bit hard to read!
–
agstudyMar 3 '13 at 7:13

yes, I had to split it into several parts to understand - I am not good enough in R to read the code with so many nested blocks...
–
Vasily AMar 3 '13 at 7:18

Yeah, I'm not crazy about how the setNames function makes it hard to see the main structure of the expression, which otherwise just involves sequentially applying merge to results of the two dcasts and the aggregate.
–
regetzMar 3 '13 at 7:37

What a great opprotunity to benchmark!
Below are some runs of the plyr method (as suggested by @agstudy) compared with the data.table method (as suggested by @Arun)
using different sample sizes (N = 900, 2700, 10800)

Summary:
The data.table method outperforms the plyr method by a factor of 7.5

Update 2: Added keying the DT as part of the metric

Adding the indexing step to the benchmark for fairness as per @MatthewDowle s comment.
However, presumably, if data.table is used, it will be in place of the data.frame and
hence the indexing will occur once and not simply for this procedure

Thanks @AnandaMahto, but it's not posted for votes, simply for relevant information. This should be a comment, but alas it is rather long ;)
–
Ricardo SaportaMar 3 '13 at 16:11

1

As I mentioned, this is interesting, and it certainly can be useful for the OP and others who stop by. Community Wiki is dead or dying, but this might have been an appropriate opportunity for using it.
–
Ananda MahtoMar 3 '13 at 16:16

1

@Ricardo Yeah I'm pretty sure someone with more time and skills could use base to beat plyr.
–
Tyler RinkerMar 3 '13 at 18:31

1

(+1) @RicardoSaporta, I find this post makes the answers complete, in a way.
–
ArunMar 3 '13 at 18:52

1

Great. Interested to see what difference the list vs paste makes (see my last edit to Arun's answer). That can be tricky to test, though, as it depends on whether the R session has seen those new strings before or not. Adding strings to R's global string cache takes some time which is skipped if the string is already there (which is one reason a rerun can be faster than a fresh R session).
–
Matt DowleMar 3 '13 at 22:00

thank you, @Ramnath! While I would still consider it as 2-steps (one for ddply and second for cast), it is the cleanest-looking solution among all proposed. Although it somehow disproves the opinion that reshape2 is by all means better than no-more-developing reshape...
–
Vasily AMar 4 '13 at 0:31