[Phylobase-devl] Conference call minutes

[Ben Bolker]

Thibaut Jombart wrote:
> 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 "".

    ?? I think we are saying it *is OK* to have multiple labels.
NA is an interesting possibility: what happens when it gets printed?
(Appears to work OK in plot.phylo ...)

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

   We should really really really try to get a series of "unit tests"
compiled, for the expected results of various phylogenetic manipulations 
-- does everyone know that if you save the output from a test file to
the /tests directory, checking the package will compare the output of
the test file to the reference output?

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

    well, "ancestor/ancestors" is fine, but "descendant/descendants" 
doesn't make that much sense to me, but if that's the way it's going
I can live with it.  There certainly doesn't seem to be any single
perfect solution.

   Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.r-forge.r-project.org/pipermail/phylobase-devl/attachments/20080324/fcdd0418/attachment.pgp