[Phylobase-devl] Votes/discussion requested
Ben Bolker
bolker at ufl.edu
Wed Dec 24 03:47:18 CET 2008
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).
>
> 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)
> 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
> 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?
>
> 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 ...)
> 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 ...
>
> 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 ...
>
> _______________________________________________
> 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
More information about the Phylobase-devl
mailing list