<blockquote>
<p>So, I think it only make sense to create a new DefeatistTreeTraverser if we want to do defeatist search with other tree types, different to SpillTrees. Would you agree?</p>
</blockquote>

<p>Yes, I agree, I think that is the right approach.  We can do that in a different PR, like you suggested.  I think single-tree defeatist search is fine, unless you want to try and implement dual-tree defeatist search.  I don't think anyone has derived a way to do that, though I think it wouldn't be too difficult.</p>

<blockquote>
<p>In that case I don't think we need to implement a new method: GetNearestChild() for each Tree Type. We could continue considering the Score() method, evaluating each child and choosing the one with lowest score.</p>
</blockquote>

<p>You are right that that would work, but in many cases (like vantage-point trees and random projection trees) we will be able to calculate which node a query point is closer to in less time.  I think it is possible to make the calculation more quickly for kd-trees too but I have not thought about that too in-depth.  Another (ugly) option is to use template metaprogramming along with TreeTraits in order to mark when a tree has a <code>GetNearestChild()</code> method available and use it, otherwise use the approach of scoring all the children.  But I am fine with adding another method to the <code>TreeType</code> API since I think that will be useful for more than just defeatist search in the future.</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#issuecomment-239602549">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJ4bFFlFkbDT_iHEq-4ZVpfvKiHzXCgJks5qfU9lgaJpZM4JZzLU">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AJ4bFOlqb7PDg3bNQugF1DiuCw1XS7P6ks5qfU9lgaJpZM4JZzLU.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#issuecomment-239602549"></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: \u003e So, I think it only make sense to create a new DefeatistTreeTraverser if we want to do defeatist search with other tree types, different to SpillTrees. Would you agree?\r\n\r\nYes, I agree, I think that is the right approach.  We can do that in a different PR, like you suggested.  I think single-tree defeatist search is fine, unless you want to try and implement dual-tree defeatist search.  I don't think anyone has derived a way to do that, though I think it wouldn't be too difficult.\r\n\r\n\u003e In that case I don't think we need to implement a new method: GetNearestChild() for each Tree Type. We could continue considering the Score() method, evaluating each child and choosing the one with lowest score.\r\n\r\nYou are right that that would work, but in many cases (like vantage-point trees and random projection trees) we will be able to calculate which node a query point is closer to in less time.  I think it is possible to make the calculation more quickly for kd-trees too but I have not thought about that too in-depth.  Another (ugly) option is to use template metaprogramming along with TreeTraits in order to mark when a tree has a `GetNearestChild()` method available and use it, otherwise use the approach of scoring all the children.  But I am fine with adding another method to the `TreeType` API since I think that will be useful for more than just defeatist search in the future."}],"action":{"name":"View Pull Request","url":"https://github.com/mlpack/mlpack/pull/747#issuecomment-239602549"}}}</script>