[Phylobase-devl] Conference call minutes

[Thibaut Jombart]

Hi all,

sorry for not being there on friday's talk.Here are some comments about 
your resolutions.
>
>
>       Node index and labels
>
> There was an extensive discussion regarding node labeling and 
> indexing. It was determined that:
>
>    1. There should be /no/ default labels
>    2. The unique label restriction should be lifted.
>
While I understand that we can do without default labels, I can think of 
a case were multiple identical labels would be useful. Even for missing 
labels, I guess that their values should be NA rather than "".

> There was also a proposal to relax the restriction on node numbers 
> being |1:length(nodes)|. e.g. valid edge matrices would be:
>
> |     [,1] [,2]
> [1,]    4    5
> [2,]    5    1
> [3,]    5    2
> [4,]    4    3
> |
>
> or
>
> |     [,1] [,2]
> [1,]    4    10
> [2,]    10   1
> [3,]    10   2
> [4,]    4    3
> |
>
> Pros:
>
>    *
>
>       The primary reason, is to have a tree framework that is
>       consistent over minor variations (different subclades analyzed,
>       adding/deleting nodes, etc)
>
>    *
>
>       Easier diffing of trees. For example, if I have a large tree of
>       birds, but only have beak trait data for a subset and tarsus
>       length for a different subset, comparing the two subsets is
>       easier if the nodes are not renumbered.
>
>    *
>
>       Lower computational overhead, tree manipulations would only
>       affect the parts of the edge matrix that change as opposed to
>       rewriting the whole matrix for each tree change.
>
Agreed.
>
> Cons:
>
>    *
>
>       Different from the |ape| implementation
>
This would not be such a problem if we knew how all the code calling ape 
functions will be affected... do we? Anyway, I think we'll diverge from 
ape soon or later, so this time may be as good as any.
>
>    *
>
>       May require rewriting some existing phylobase code
>
I would say 'likely requires to write new phylobase code instead of 
previous calls to ape functions'.
>
>    *
>
>       May make iterating over edge matrix trickier
>
I don't think so: for(i in nodes) is just as quick as for(in in 1:nNodes).
>
>    *
>
>       May be harder to do checks on class objects?
>
>
>       Function naming
>
>    *
>
>       |NexusToPhylo4()|, |NexusToDataFrame()|, |NexusToPhylo4D()|, and
>       |read.nexustreestring()| should be combined into one function
>       with options to get different values. The name |read.nex()| was
>       suggested for this new function.
>
Has my vote.
>
>    *
>
>       Marguerite agreed to look into a |NAMESPACE| that might ease
>       future package conflicts.
>
>    *
>
>       A decision was made to use |camelCase()| for function names.
>
>    *
>
>       Proposed tree walking function names:
>
>       Internally, define “one step” ancestor/descendant functions,
>       called |children()| and |ancestor()|. Then there are recursive
>       functions
>
>       |ancestors(..., which = c("all", "parent")) # default to "all" since ancestor() exists
>
>       descendants(..., which = c("children", "tips", "all")) # first option calls children()
>       |
>
>       The only thing that might be confusing here is the existence of
>       a separate function, children(), that does the same thing as
>       descendants with its default option. An alternative would be to
>       have “children” be invisible/internal, or defined within
>       descendants.
>
My naive question is: why not 'ancestor()', 'descendant()' and their 
plurial forms?
>
>
>       Miscellaneous
>
>    *
>
>       Marguerite will be teaching a NESCENT R comparative methods
>       class at the end of July. We should aim to have a usable package
>       by that time so she can evangelize it.
>
>    *
>
>       TODOs are better placed in the R-forge ticket tracker where they
>       can be vigorously debated. The TODO file is currently a bit
>       sprawling, and cannot be changed by people without commit access.
>
Agreed, I also prefer the bug tacking system.

Cheers,

Thibaut.

-- 
######################################
Thibaut JOMBART
CNRS UMR 5558 - Laboratoire de Biométrie et Biologie Evolutive
Universite Lyon 1
43 bd du 11 novembre 1918
69622 Villeurbanne Cedex
Tél. : 04.72.43.29.35
Fax : 04.72.43.13.88
jombart at biomserv.univ-lyon1.fr
http://lbbe.univ-lyon1.fr/-Jombart-Thibaut-.html?lang=en
http://adegenet.r-forge.r-project.org/