[Phylobase-devl] Votes/discussion requested

Ben Bolker bolker at ufl.edu
Wed Dec 24 04:02:34 CET 2008


  [PDC didn't reply to the list, plus I have one tiny additional comment]

Peter Cowan wrote:
> 
> On Dec 23, 2008, at 9:47 PM, Ben Bolker wrote:
> 
>> Steven Kembel wrote:
>>> 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).
> PDC, I agree, however the consequence of handing the ape reorder.phylo()
> a tree in the wrong order is an infinite loop what crashes R. Perhaps
> Emmanuel has a suggestion for how we should handle this.
BMB: Well, crashing R is always a bug, so we can probably get EP to
test/block this?

>>> 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)
> PDC I agree lets drop things that we don't plan to use, so that end
> users don't start using function we don't want to support.
> 
>>> 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
> PDC, I think this can be done easily, but I think we have enough on our
> plate for this pending release.
> 
>>> 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?
> PDC -- I can do this, after I finish up some plotting issues.  I say add
> it to the tracker.  That way we'll easily be reminded.
> 
>>> 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 ...)
> PDC I'll implement this style arrangement in the reorder commands. 
> Perhaps known problem functions could be added to the tracker, I can
> help fix as necessary.
> 
>>> 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 ...
> PDC No opinion.
> 
>>> 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 ...
> PDC No strong opinion here, but if I can help out anywhere, let me know.
> 


-- 
Ben Bolker
Associate professor, Biology Dep't, Univ. of Florida
bolker at ufl.edu / www.zoology.ufl.edu/bolker
GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc


More information about the Phylobase-devl mailing list