[Phylobase-devl] where are we??

[Steven Kembel]

Hi,

> 1. merge my branch (with the aforementioned controversial
> ordering)  {Peter, can you help with this if/when we
> decide to go for it?}
+1, prefer the named vector for labels in your branch.

Isn't the controversial ordering already in the trunk? Related to  
ordering, I couldn't tell if there is a consensus on what to do about  
edge matrix reordering. Marguerite and Thibaut seemed against edge  
matrix reordering vs. node ids, others pro or neutral.

For rooted trees, it's true that every node has an edge associated  
with it. Would reverting to the old reorder methods that keep nodes  
and edge matrix in same index order (edge matrix in node id order),  
create a lookup for edge/node order under reordering, instead of  
actually reordering the edge matrix, address some of the concerns  
raised by Marguerite and Thibaut about not mixing up edge and node  
ordering for rooted trees?

> 2. see what we can do to detect & fix problems with unrooted trees:
> this includes a lot of Steve's "to do" list (sorting out nodeId,
> nNode, etc.)

I can work on this once we decide what to do about unrooted trees, I  
think of the 3-4 options I suggested everyone voted for a different one.
Do we want to try to add an imaginary root edge to unrooted trees that  
we strip out for printing, export, etc? i.e. we give one node in an  
unrooted tree an edge so every node has a unique edge (like in a  
rooted tree), this should allow most of the existing construction,  
check and summary methods to work with unrooted trees? Other options  
were to have separate code for constructing, checking, printing, etc.  
of unrooted and rooted trees, or to actually create a different class  
for rooted vs. unrooted trees?

> 4.  PDC proposes that we change the NA in the root-node-row
> to (-1) instead; I propose that we add a "dropRoot" function
> (which just operates on a raw edge matrix, not on a phylo4
> object) to abstract the operation of dropping the appropriate
> row (essentially substituting for places where we have na.omit
> or edge[!is.na(edge[,1]),] in the code now

I'd prefer the dropRoot function vs. changing NA's to -1 in edge.  
dropRoot might also help if we go with adding an imaginary edge to  
unrooted trees, could just dropRoot whenever we want to summarize  
unrooted trees.

> 6. with some input from Emmanuel, implement SOME form of
> checking/consistency rule for ordering when importing/exporting
> from/to ape

as(phylo,"phylo4") should keep the ape ordering of nodes/edges during  
import (with insertion of root edge into phylo4 edge matrix).
Once we make a decision about whether we want to keep direct  
reordering of the edge matrix, I think all that needs to be done for  
export to phylo is to make sure we strip out the root edge and then  
have nodes/edges follow the ape ordering of (tips,int.nodes) in edge?

> I propose that we DELAY:
> 2. adding metadata/annotation slots, although if we know
> their GENERAL form it would be nice to add them to phylo4[d]
> objects now because adding slots later breaks backward compatibility
> of saved objects (but we may just have to bite the bullet and
> do it later).  In particular if these were slots of type list()
> we could be vague about what we were going to put in (at the
> cost of less-strong typing of the objects)

Hilmar had suggested that these slots could be tag/value lists. If we  
add @metadata and @annotation slots of type list for now, can we  
enforce checking of tags later once we know what metadata and  
annotations will look like?

Cheers,
Steve