[Phylobase-devl] Votes/discussion requested

Brian O'Meara bcomeara at nescent.org
Wed Dec 24 09:07:49 CET 2008


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.
>
>>
>> 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
>
>
>> 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
>
>
>> 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.
>
>>
>> 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
>
>
>> 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.


>
>>
>> 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
>
>>
>> _______________________________________________
>> Phylobase-devl mailing list
>> Phylobase-devl at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl
>
>
> -- 
> 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
> _______________________________________________
> Phylobase-devl mailing list
> Phylobase-devl at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl



More information about the Phylobase-devl mailing list