<p>In <a href="https://github.com/mlpack/mlpack/pull/746#discussion_r76267351">src/mlpack/core/tree/binary_space_tree/binary_space_tree_impl.hpp</a>:</p>
<pre style='color:#555'>&gt; @@ -877,7 +879,43 @@ template&lt;typename MetricType,
&gt;           template&lt;typename BoundMetricType, typename...&gt; class BoundType,
&gt;           template&lt;typename SplitBoundType, typename SplitMatType&gt;
&gt;               class SplitType&gt;
&gt; +size_t BinarySpaceTree&lt;MetricType, StatisticType, MatType, BoundType,
&gt; +    SplitType&gt;::PerformSplit(
&gt; +    MatType&amp; data,
&gt; +    const size_t begin,
&gt; +    const size_t count,
&gt; +    const typename UBTreeSplit&lt;BoundType&lt;MetricType&gt;,
&gt; +                               MatType&gt;::SplitInfo&amp; splitInfo)
&gt; +{
&gt; +  return SplitType&lt;BoundType&lt;MetricType&gt;, MatType&gt;::PerformSplit(data, begin,
&gt; +      count, splitInfo);
&gt; +}
</pre>
<p>Instead of having a specific overload for <code>UBTreeSplit</code>, what do you think of this approach instead:</p>

<ul>
<li>Move <code>BinarySpaceTree::PerformSplit()</code> (the non-specific version) into the <code>math</code> namespace somewhere as an auxiliary standalone function.</li>
<li>In <code>BinarySpaceTree::SplitNode()</code>, don't call <code>BinarySpaceTree::PerformSplit()</code> but instead call <code>SplitType::PerformSplit()</code>.</li>
<li>In each <code>SplitType</code>, <code>PerformSplit()</code> can just be a call to the function in the <code>math</code> namespace, or in the case of <code>UBTreeSplit</code>, it can be the custom strategy you are using there.</li>
</ul>

<p>What do you think?  If you like it, we can do it.  If you do like it, I can do the refactoring or you can, it's your choice. :)</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/746/files/f17843fc8e8ef2b1c4b04d572c521575f20a1f3c#r76267351">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJ4bFDXDLyDsTs7EOnR4nbt3pHkeY1RFks5qjbZNgaJpZM4JZrEi">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AJ4bFK56hoa_xXo-F91jVtElkT2KSvIdks5qjbZNgaJpZM4JZrEi.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/746/files/f17843fc8e8ef2b1c4b04d572c521575f20a1f3c#r76267351"></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 #746: Instead of having a specific overload for `UBTreeSplit`, what do you think of this approach instead:\r\n\r\n * Move `BinarySpaceTree::PerformSplit()` (the non-specific version) into the `math` namespace somewhere as an auxiliary standalone function.\r\n * In `BinarySpaceTree::SplitNode()`, don't call `BinarySpaceTree::PerformSplit()` but instead call `SplitType::PerformSplit()`.\r\n * In each `SplitType`, `PerformSplit()` can just be a call to the function in the `math` namespace, or in the case of `UBTreeSplit`, it can be the custom strategy you are using there.\r\n\r\nWhat do you think?  If you like it, we can do it.  If you do like it, I can do the refactoring or you can, it's your choice. :)"}],"action":{"name":"View Pull Request","url":"https://github.com/mlpack/mlpack/pull/746/files/f17843fc8e8ef2b1c4b04d572c521575f20a1f3c#r76267351"}}}</script>