<p>In <a href="https://github.com/mlpack/mlpack/pull/747#discussion_r75184272">src/mlpack/methods/neighbor_search/spill_search_rules_impl.hpp</a>:</p>
<pre style='color:#555'>&gt; +    // better, then take it.
&gt; +    if (SortPolicy::IsBetter(queryNode.Parent()-&gt;Stat().FirstBound(),
&gt; +        worstDistance))
&gt; +      worstDistance = queryNode.Parent()-&gt;Stat().FirstBound();
&gt; +  }
&gt; +
&gt; +  // Could the existing bounds be better?
&gt; +  if (SortPolicy::IsBetter(queryNode.Stat().FirstBound(), worstDistance))
&gt; +    worstDistance = queryNode.Stat().FirstBound();
&gt; +
&gt; +  // Cache bounds for later.
&gt; +  queryNode.Stat().FirstBound() = worstDistance;
&gt; +
&gt; +  worstDistance = SortPolicy::Relax(worstDistance, epsilon);
&gt; +
&gt; +  return worstDistance;
</pre>
<p>Thanks!  The changes look really nice.  It seems that moving the <code>Score()</code> calculation into the defeatist traversers ties those traversers to the nearest neighbor search problem.  But, it also seems that the other PR that is open for greedy traversers introduces some new functions into the Rules classes to handle that, and once we merge the other PR we can easily refactor the defeatist traverser here and it will be abstract enough to handle any rules case again.  (...as long as that rules case can support greedy search)  What do you think?  Is that a reasonable plan?</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/fe090ee13c7cad79e2b7eb8b6690628ba3ead1ed#r75184272">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJ4bFNMojr7fPYeemN1bha35Quc4Ru-2ks5qg1j9gaJpZM4JZzLU">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AJ4bFCA4vqCbecnFLEIwsJ6pOSrsVu7Vks5qg1j9gaJpZM4JZzLU.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/fe090ee13c7cad79e2b7eb8b6690628ba3ead1ed#r75184272"></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: Thanks!  The changes look really nice.  It seems that moving the `Score()` calculation into the defeatist traversers ties those traversers to the nearest neighbor search problem.  But, it also seems that the other PR that is open for greedy traversers introduces some new functions into the Rules classes to handle that, and once we merge the other PR we can easily refactor the defeatist traverser here and it will be abstract enough to handle any rules case again.  (...as long as that rules case can support greedy search)  What do you think?  Is that a reasonable plan?"}],"action":{"name":"View Pull Request","url":"https://github.com/mlpack/mlpack/pull/747/files/fe090ee13c7cad79e2b7eb8b6690628ba3ead1ed#r75184272"}}}</script>