[Phylobase-devl] Votes/discussion requested

François Michonneau francois.michonneau at gmail.com
Wed Dec 24 12:00:09 CET 2008


On Wed, 2008-12-24 at 03:07 -0500, Brian O'Meara wrote:
> On Dec 23, 2008, at 9:47 PM, Ben Bolker wrote:
> 
> > Steven Kembel wrote:
> >> Hi everyone,
> >>
> >> It might be hard to get everyone together at the same time for a
> >> discussion but it sounds like there are some pressing issues that we
> >> should vote on/discuss. Can we do this via email? Here are the main
> >> points listed on the wiki at the moment for voting/disussion, feel
> >> free to reply and add your vote/opinion on these, and whether you
> >> think they need to be in the 1.5 CRAN release we are preparing. These
> >> are taken from the wiki at:
> >> https://www.nescent.org/wg_phyloinformatics/Phylobase_Hackathon
> >>
> >> 1. Ordering issues translating to/from ape
> >> SWK - I feel like these are issues with ape and not phylobase. I'd
> >> rather not reorder trees by default on export since maintaining order
> >> can be useful. Suggest that on import from ape @order = 'unknown'.
> > BMB - mostly agree -- also I like preserving the possibility of
> > strict roundtrip -- but I am worried about safety of objects exported
> > from phylobase into ape. Consider warning on export of unknown
> > objects (no way to turn this off unless we set a global option or
> > have an explicit export function, but user can explicitly reorder).
> BCO - agree with Steve.
FM - I don't think I have enough information on this to have a strong
opinion. It seems to me that the word 'unknown' can actually refer to
either 'default' (case of an object created by phylobase) or
'unknown' (in the sense, tree imported from another package and so we
can't guarantee the order). I don't like software that do things "in
your back" (like reordering during export) but I think I would hate even
more that we loose the compatibility between phylobase and ape trees.



> >> 2. Deprecate/drop: (a) reorder(phylo), printphylo, $
> >> SWK - fine with dropping them for 1.5. There may also be some  
> >> orphaned
> >> functions in the treestruc.R file.
> > BMB fine with me (would like to check printphylo to see if it does
> > anything summary(phylo4) doesn't)
> BCO - neutral
FM - I don't really care about reorder(phylo). It seems that printphylo
isn't really useful. $ just confuses users used to S3 classes.


> >> 3. Namespace
> >> SWK - no strong opinion, only for 1.5 if they are absolutely  
> >> necessary
> >> for things to work properly +/or someone can do this easily?
> > BMB would like to defer, don't like them anyway
> BCO - neutral
FM - I don't quite see the advantages (or disadvantages) of having a
NAMESPACE, so neutral I guess.


> >> 4. Naming conventions
> >> SWK - sounds good, will keep an eye out and try to follow naming
> >> conventions for 1.5, thanks for the naming table
> > BMB can someone volunteer to implement, or write scripts?
> BCO - Good for CRAN release (stabilize API). I might be able to do  
> this, but have several deadlines coming up (applying for a third year  
> of postdoc funding by Jan. 10), so I can't guarantee it.
FM - If I manage to finish what I started then I could work on renaming
the functions.

> >> 5. Rordering conventions at @ and accessor levels
> >> SWK - This is crucial and we should decide soon, needs to be sorted
> >> out for 1.5. I think that many of the problems we're having with
> >> labels and reordering are due to the fact that until now we treated
> >> nodes and edges as interchangable. i.e. we had node labels in edge
> >> matrix order, but these labels should really be associated with  
> >> nodes,
> >> not with edges. This assumption caused things to break once edges and
> >> nodes were not equivalent (now that root edge is in the edge matrix
> >> and we allow edge matrix reordering, or for unrooted trees). I think
> >> we need to be very clear about whether methods are actually operating
> >> on nodes or edges.
> >> I suggest that edge, edge.labels and edge.lengths (branch lengths)  
> >> are
> >> in 'edge' order. Everything else (node labels, tip labels) should be
> >> in node id order. nodeId can translate between these two orders.
> >> Reorder can act on the edge* only since the underlying node ids will
> >> not change.
> >> Best guess on what this means in terms of work for 1.5 - currently  
> >> the
> >> constructor, tree_check, print, as methods are at least partly making
> >> a distinction between nodes and edges and their respective ordering
> >> but need to be checked. phylo4d, tdata, prune methods probably will  
> >> be
> >> broken by this change (they assume nodes = edges when linking data  
> >> and
> >> labels to tree?) and need to be updated?
> > BMB agree.  Let's go for it.  Who starts?
> > (This should be a nuisance but relatively easy to fix in those cases
> > where we just have to disable reordering ...)
> BCO - neutral
FM - It's definitely a crucial issue. Perhaps we could track node.labels
and tip.labels by using named vectors, the names of the vector would be
the nodeId.


> >> 6. vcov/distance matrix translation
> >> SWK - No strong opinion, this seems very useful but maybe not for  
> >> 1.5?
> > BMB if I can do this quickly/easily it will be fun and shouldn't
> > destabilize anything else ...
> BCO - I'd find this useful. Making sure order of taxa in matrix and  
> exported data would be great, too.
FM - I agree with Brian.


> >> 7. Rooted vs. unrooted trees
> >> SWK - I think many methods were assuming a rooted tree. Should at
> >> least figure how to check for whether a tree is rooted in a robust  
> >> way
> >> in tree_check for 1.5 and make sure print/as methods work properly  
> >> for
> >> unrooted trees. Most of the hiccups are related to the previous point
> >> about edges and nodes not being equivalent, maybe solving the label/
> >> reorder/edge/nodeId issues will help solve this?
> > BMB would be nice ...
> BCO - yes
FM - sounds good to me



More information about the Phylobase-devl mailing list