Oliver Purschke writes:

i just started to play around with the multitable package and i think it would really extent my toolbox if “data.lists” could handle phylogenies. i guess one could include a phylogenetic distance matrix but then distances need to be recalculated if one adds or deletes species from the community data set.
any hints are welcome.

It would really extend my toolbox too if data lists could handle phylogenies! Its one of the things that’s on my ‘to do list’…What I do now is to use eigenvectors of the phylogenetic distance matrix as variables representing the phylogeny, but you are absolutely correct that the problem here is that these eigenvectors (and your distance matrices) would have to be recalculated if species lists are changed.

Here is some code I wrote to handle phylogenetic distance matrices in multitable (but it is far from slick as Oliver points out below):

``````
library(multitable)
library(picante)

# fake data that comes with multitable
data(fake.community)
print(fake.community)
summary(fake.community)

# make a tree for the fake species
set.seed(1)
tree <- rcoal(3)
tree\$tip.label <- dimnames(fake.community)[[3]]
print(tree)

# compute the distances
phylodist <- cophenetic(tree)
print(phylodist)

# convert the columns into variables and rows into replicates --
# in other words, matrices have two dimensions of replication (rows and columns)
# whereas data frames have only one (the rows) because columns represent variables
phylodist <- as.data.frame(phylodist)

# another way to look at this last step is that if we didn't convert to a
# data frame we'd get an error:
fake.community + variable(cophenetic(tree), c('species','species'))

colnames(phylodist) <- paste(colnames(phylodist), 'phylo.dist', sep = '.')

# add the distance information to the data list
dl <- fake.community + variableGroup(as.data.frame(phylodist), dimids = 'species')
print(dl)
summary(dl)
``````

Oliver writes back:

your approach only seems to work for cases where the tip.labels are in the same order as the species names in the community data.frame, which requires additional reordering of the species and the trait data.

He’s right again! But I think its a good starting point.

Conclusion: I need some kind of better ‘workaround’ for this stuff.