<p>In <a href="https://github.com/mlpack/mlpack/pull/747#discussion_r74316245">src/mlpack/core/tree/spill_tree/spill_tree_impl.hpp</a>:</p>
<pre style='color:#555'>&gt; +  }
&gt; +
&gt; +  std::vector&lt;size_t&gt; leftPoints, rightPoints;
&gt; +  // Split the node.
&gt; +  overlappingNode = SplitPoints(tau, rho, points, leftPoints, rightPoints);
&gt; +
&gt; +  // We don&#39;t need the information in points, so lets clean it.
&gt; +  std::vector&lt;size_t&gt;().swap(points);
&gt; +
&gt; +  // Now we will recursively split the children by calling their constructors
&gt; +  // (which perform this splitting process).
&gt; +  left = new SpillTree(this, leftPoints, tau, maxLeafSize, rho);
&gt; +  right = new SpillTree(this, rightPoints, tau, maxLeafSize, rho);
&gt; +
&gt; +  // Update count number, to represent the number of descendant points.
&gt; +  count = left-&gt;NumDescendants() + right-&gt;NumDescendants();
</pre>
<p>I see what you mean; I did not understand what you wrote the first time.  Sorry about that.  I don't think holding a list of unique points in each node is a good solution, and I can't think of any other easy solution to this problem.  Any way I can think of to organize the points and still get access to unique descendants from arbitrary levels requires caching potentially very much.  So I think unfortunately we should go with your second solution---disable this type of tree for rank-approximate nearest neighbor search or other algorithms that depend on <code>NumDescendants()</code> being correct.  Let's do that like this:</p>

<ul>
<li>add a <code>TreeTraits</code> element indicating whether <code>NumDescendants()</code> returns the number of unique descendants</li>
<li>add a <code>static_assert</code> in <code>RASearch</code> to ensure that with the given tree type, the number of unique descendants is correctly returned by <code>NumDescendants()</code>, using that new <code>TreeTraits</code> element</li>
</ul>

<p>What do you think?  I think that's the best we can do here, unfortunately.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/mlpack/mlpack/pull/747/files/a71b57caa90311f5542180bc0553449c3691395d#r74316245">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJ4bFJks_Wns0Q5lLvYGYD3FavXjbE64ks5qeipQgaJpZM4JZzLU">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AJ4bFH_pEojrIzsMzyTPi4z08Wze3dStks5qeipQgaJpZM4JZzLU.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/mlpack/mlpack/pull/747/files/a71b57caa90311f5542180bc0553449c3691395d#r74316245"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/mlpack/mlpack","title":"mlpack/mlpack","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/mlpack/mlpack"}},"updates":{"snippets":[{"icon":"PERSON","message":"@rcurtin in #747: I see what you mean; I did not understand what you wrote the first time.  Sorry about that.  I don't think holding a list of unique points in each node is a good solution, and I can't think of any other easy solution to this problem.  Any way I can think of to organize the points and still get access to unique descendants from arbitrary levels requires caching potentially very much.  So I think unfortunately we should go with your second solution---disable this type of tree for rank-approximate nearest neighbor search or other algorithms that depend on `NumDescendants()` being correct.  Let's do that like this:\r\n\r\n - add a `TreeTraits` element indicating whether `NumDescendants()` returns the number of unique descendants\r\n - add a `static_assert` in `RASearch` to ensure that with the given tree type, the number of unique descendants is correctly returned by `NumDescendants()`, using that new `TreeTraits` element\r\n\r\nWhat do you think?  I think that's the best we can do here, unfortunately."}],"action":{"name":"View Pull Request","url":"https://github.com/mlpack/mlpack/pull/747/files/a71b57caa90311f5542180bc0553449c3691395d#r74316245"}}}</script>