<p>In <a href="https://github.com/mlpack/mlpack/pull/747#discussion_r75204544">src/mlpack/methods/neighbor_search/spill_search_impl.hpp</a>:</p>
<pre style='color:#555'>> + typename MatType,
> + template<typename HyperplaneMetricType> class HyperplaneType,
> + template<typename SplitBoundT, typename SplitMatT> class SplitType>
> +void SpillSearch<MetricType, MatType, HyperplaneType, SplitType>::
> +Search(const MatType& querySet,
> + const size_t k,
> + arma::Mat<size_t>& neighbors,
> + arma::mat& distances)
> +{
> + if (Naive() || SingleMode())
> + neighborSearch.Search(querySet, k, neighbors, distances);
> + else
> + {
> + // For Dual Tree Search on SpillTrees, the queryTree must be built with non
> + // overlapping (tau = 0).
> + Tree queryTree(querySet, 0 /* tau */, leafSize, rho);
</pre>
<p>When I originally designed the <code>NeighborSearch</code> class, my intention was to make it as tree-independent as possible (or, well, that's what happened in the end). So it doesn't hold any <code>leafSize</code> parameter despite the fact that the <code>BinarySpaceTree</code> uses it. The policy has always been, <code>NeighborSearch</code> will build your trees with the default parameters, and if you don't want the default parameters, you must pass the trees. I think that we should continue that policy here, so I don't think it's advisable to have <code>leafSize</code>, <code>rho</code>, and <code>tau</code> stored in the class. If the user wants to specify those, they can build the tree themselves. (This means that <code>NSModel</code> will need to store those parameters, if they can be specified from the command-line.)</p>
<p>For the traversers, an idea is to add two more template parameters to <code>NeighborSearch</code> that specify the desired single-tree and dual-tree traversers (and default to the defaults of the TreeType).</p>
<p>Then we could typedef <code>SpillTreeKNN = NeighborSearch<EuclideanDistance, arma::mat, SPTree, SPTree::DefeatistSingleTreeTraverser, SPTree::DefeatistDualTreeTraverser></code> (or whatever the names and syntax may be). This, plus the template specialization I suggested for building the query tree for spill tree search, should be sufficient to avoid the need for the <code>SpillSearch</code> class at all, and keep the number of files and classes down. What do you think? Have I overlooked a detail?</p>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<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#r75204544">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJ4bFJPJSgmGixED9WHvne9CHvM_tc8Uks5qg3RGgaJpZM4JZzLU">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AJ4bFKHx-BR9hD-XCymNv0PZpELnaDZwks5qg3RGgaJpZM4JZzLU.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#r75204544"></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: When I originally designed the `NeighborSearch` class, my intention was to make it as tree-independent as possible (or, well, that's what happened in the end). So it doesn't hold any `leafSize` parameter despite the fact that the `BinarySpaceTree` uses it. The policy has always been, `NeighborSearch` will build your trees with the default parameters, and if you don't want the default parameters, you must pass the trees. I think that we should continue that policy here, so I don't think it's advisable to have `leafSize`, `rho`, and `tau` stored in the class. If the user wants to specify those, they can build the tree themselves. (This means that `NSModel` will need to store those parameters, if they can be specified from the command-line.)\r\n\r\nFor the traversers, an idea is to add two more template parameters to `NeighborSearch` that specify the desired single-tree and dual-tree traversers (and default to the defaults of the TreeType).\r\n\r\nThen we could typedef `SpillTreeKNN = NeighborSearch\u003cEuclideanDistance, arma::mat, SPTree, SPTree::DefeatistSingleTreeTraverser, SPTree::DefeatistDualTreeTraverser\u003e` (or whatever the names and syntax may be). This, plus the template specialization I suggested for building the query tree for spill tree search, should be sufficient to avoid the need for the `SpillSearch` class at all, and keep the number of files and classes down. What do you think? Have I overlooked a detail?"}],"action":{"name":"View Pull Request","url":"https://github.com/mlpack/mlpack/pull/747/files/fe090ee13c7cad79e2b7eb8b6690628ba3ead1ed#r75204544"}}}</script>