I think I agree Matthew, that the matrix in #202 is a little too restrictive for multitable, although I'll look into it more. The main benefits of the multitable package really emerge when several vectors, matrices, or arrays with different dimensions and lengths are to be related in a single object (called a data.list). Such situations are more complex than #202. The simplest situation for which multitable is interesting is when you have a matrix-valued response variable, with a data.frame of predictors for the rows and another data.frame of predictors for the columns. In my field of ecology this is called the fourth-corner problem (http://www.esajournals.org/doi/abs/10.1890/0012-9658%281997%29078%5B0547:RBTHST%5D2.0.CO%3B2).
Steve. On Thu, 2011-09-29 at 13:33 -0500, Branson Owen wrote: > To data.table core team, will multitable (data.list) package make it > easy to implement feature #202? I'm not sure it will. The matrix that #202 is about would have the same number of rows as the data.table. That might be too restrictive for multitable. All the examples I know of so far can be implemented as long or wide format with NAs (or no rows), or joining together tables. multitable seems to be encapsulating the tables and the relationships into one object i.e. a level above data.table? -- View this message in context: http://r.789695.n4.nabble.com/A-new-package-multitable-data-list-remind-me-of-a-long-existing-feature-request-202-and-discussion-td-tp3857125p3867526.html Sent from the datatable-help mailing list archive at Nabble.com. _______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
