<html><head><base href="file:///tmp/tm_mail_9N2Bvh.html"><title>confernce call mins</title></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><base href="file:///tmp/tm_mail_9N2Bvh.html"><div style="font-family: 'Lucida Grande'; font-size: 12px; color: black; text-align: left; ">Steve, Marguerite, Ben and I talked yesterday until Ben was relegated to typing his responses. Below is a summary of the conversation.</div>
<h3 id="mac_os_x_builds">Mac OS X builds</h3>
<p>Mac OSX building still failing on R-forge and certain macs. This may be related to the configuration files. Additionally, it appears that the “Examples” folder is actually necessary for the package to auto-configure. </p>
<p>Would someone who understands the make and configure systems volunteer to help diagnose the build issues and ensure we have the necessary files to build from ‘scratch’?</p>
<h3 id="node_index_and_labels">Node index and labels</h3>
<p>There was an extensive discussion regarding node labeling and indexing. It was determined that:</p>
<ol>
<li>There should be <em>no</em> default labels</li>
<li>The unique label restriction should be lifted.</li>
</ol>
<p>There was also a proposal to relax the restriction on node numbers being <code>1:length(nodes)</code>. e.g. valid edge matrices would be:</p>
<pre><code> [,1] [,2]
[1,] 4 5
[2,] 5 1
[3,] 5 2
[4,] 4 3
</code></pre>
<p>or</p>
<pre><code> [,1] [,2]
[1,] 4 10
[2,] 10 1
[3,] 10 2
[4,] 4 3
</code></pre>
<p>Pros:</p>
<ul>
<li><p>The primary reason, is to have a tree framework that is consistent over minor variations (different subclades analyzed, adding/deleting nodes, etc) </p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ul>
<p>Cons:</p>
<ul>
<li><p>Different from the <code>ape</code> implementation</p></li>
<li><p>May require rewriting some existing phylobase code</p></li>
<li><p>May make iterating over edge matrix trickier</p></li>
<li><p>May be harder to do checks on class objects?</p></li>
</ul>
<h3 id="function_naming">Function naming</h3>
<ul>
<li><p><code>NexusToPhylo4()</code>, <code>NexusToDataFrame()</code>, <code>NexusToPhylo4D()</code>, and <code>read.nexustreestring()</code> should be combined into one function with options to get different values. The name <code>read.nex()</code> was suggested for this new function.</p></li>
<li><p>Marguerite agreed to look into a <code>NAMESPACE</code> that might ease future package conflicts.</p></li>
<li><p>A decision was made to use <code>camelCase()</code> for function names.</p></li>
<li><p>Proposed tree walking function names:</p>
<p>Internally, define “one step” ancestor/descendant functions, called <code>children()</code> and <code>ancestor()</code>. Then there are recursive functions</p>
<pre><code>ancestors(..., which = c("all", "parent")) # default to "all" since ancestor() exists
descendants(..., which = c("children", "tips", "all")) # first option calls children()
</code></pre>
<p>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.</p></li>
</ul>
<h3 id="miscellaneous">Miscellaneous</h3>
<ul>
<li><p>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. </p></li>
<li><p>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. </p></li>
</ul>
<div style="font-family: 'Lucida Grande'; font-size: 12px; color: black; text-align: left; "><br class="webkit-block-placeholder"></div></body></html>