[Phylobase-devl] Votes/discussion requested

[Marguerite Butler]

On Dec 24, 2008, at 1:00 AM, François Michonneau wrote:

> 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.
MB - Same as FM. How about @order='ape'?  I strongly agree that things  
should be coded as transparently as possible with as few decisions  
which would be surprising to others.

>
>>>> 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.
MB - 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
> FM - I don't quite see the advantages (or disadvantages) of having a
> NAMESPACE, so neutral I guess.
MB - If I understood why we wanted a namespace, I would be happy to do  
it in mid-January. What objects do we want internal, what do we want  
to export?
>
>
>
>>>> 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.
MB - Like this idea a lot. Can help in mid-January. But where is the  
naming table?
>
>
>>>> 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.
MB - I have been really out of it, and I don't know what's on, so  
sorry if this comes out strongly, but ---

This one is very important, and I think it's a very bad idea to unlink  
the edges and nodes. Edges and nodes are intimately linked. In my  
mind, the edge is simply the branch below the node. So to have edges  
in one order and nodes in another order makes no sense to me at all.  
Why don't we simply give node ID's in "edge" order as you are using  
it? otherwise, there is HUGE potential for confusion. And we would  
need yet another index that indicates a mapping of the node ID to the  
edge matrix.

Instead, why don't we just decide on a standard ordering for phylobase  
number the node ID's in this way, and then allow the edge matrix and  
nodeID (and all data vectors) to be reordered as needed for whatever  
functions.  Using the node ID, we can easily  put everything back to  
the "default" phylobase order, BUT ONLY IF all objects (edge matrix,  
branch lengths, labels, etc etc are in the SAME order. Don't "break"  
the integrity of the object just for programming convenience. There is  
just too much danger for confusion. I, for one, would stop using  
phylobase, because it's just too hard to remember the peculiarities of  
the way the object is constructed. Everytime I wanted to do something,  
I'd have to relearn the rules.
>
>
>
>>>> 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.
MB - Also 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
MB - Yes, a necessary function. I've forgotten how rooted vs unrooted  
trees are represented differently in Nexus format, but we should be  
able to figure out a convention. I'm not sure what you folks mean  
about edges and nodes not being equivalent. Of course they are not  
equivalent in the strict sense, but you can't have edges without  
nodes, and vice versa. The fundamental unit of a branching tree is a  
node, with associated edges etc. So the edge is just the branch  
ancestral (that leads to) the node. This takes care of everything --  
tips, internal nodes, even the most basal node.
>
>
> _______________________________________________
> 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