<p>In <a href="https://github.com/mlpack/mlpack/pull/747#discussion_r75182988">src/mlpack/methods/neighbor_search/knn_main.cpp</a>:</p>
<pre style='color:#555'>&gt; @@ -209,12 +245,6 @@ int main(int argc, char *argv[])
&gt;      Log::Info &lt;&lt; &quot;Loaded kNN model from &#39;&quot; &lt;&lt; inputModelFile &lt;&lt; &quot;&#39; (trained on &quot;
&gt;          &lt;&lt; knn.Dataset().n_rows &lt;&lt; &quot;x&quot; &lt;&lt; knn.Dataset().n_cols &lt;&lt; &quot; dataset).&quot;
&gt;          &lt;&lt; endl;
&gt; -
&gt; -    // Adjust singleMode and naive if necessary.
&gt; -    knn.SingleMode() = CLI::HasParam(&quot;single_mode&quot;);
&gt; -    knn.Naive() = CLI::HasParam(&quot;naive&quot;);
&gt; -    knn.LeafSize() = size_t(lsInt);
&gt; -    knn.Epsilon() = epsilon;
</pre>
<p>I see what you mean.  There are really two separate concerns in the comments you made; I'll address them in reverse order:</p>

<p>I agree that a <code>-m</code> option would be a nice idea, since the number of options for these neighbor searching programs we have are exploding as we add so many types of trees and types of search!  Unfortunately we will have some reverse compatibility to contend with, but it should not be a huge issue, just annoying.</p>

<p>Onto the other issue, allowing the user to specify some options at query time can provide functionality we don't otherwise have: for instance, the user can specify a query tree with a different leaf size, and more importantly, a user can train a model (i.e. build a reference tree) once, and then use that saved model to do both single-tree and dual-tree search.  This can save a lot of time, for instance if the tree took a long time to build (which is often the case with cover trees).  This is also true of the epsilon parameter---I can do nearest neighbor search with a lot of different epsilon levels.</p>

<p>So, I guess, the documentation was wrong about what was actually happening before.  A better way to put it would be this:  If <code>--single_mode</code>, <code>--naive</code>, <code>--leaf_size</code>, or <code>--epsilon</code> are specified along with <code>--input_model_file</code>, then these options will be taken into account for the search.  For <code>--leaf_size</code>, the option will only apply to the reference tree.  The new model preferences will not be saved unless <code>--output_model_file</code> is specified.</p>

<p>Really there are two different types of options there; one can be encapsulated by the <code>--mode</code> parameter you suggested; the other (<code>--leaf_size</code>) is a specific parameter for the query tree.  I am willing to believe that the use-case for different-leaf-size query trees is so niche that nobody is going to do it, and we can force the user to say that if they are going to build a query tree, then it will be built with the same options as the reference tree, and if they don't like that, then they will need to write C++ and build their trees themselves.  But we can't remove the option to allow the user to specify a different search mode.</p>

<p>If you prefer, for the second part, we can leave that for a separate issue, leave the code in currently to set <code>LeafSize()</code> and the other parameters, and then open another Github issue and we can work that out separately.</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#r75182988">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJ4bFJzPtOrqO1gR2C8Dsqycv5_eD29iks5qg1dcgaJpZM4JZzLU">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AJ4bFED3moquyEJeA1_2AMeDCJSyDJsWks5qg1dcgaJpZM4JZzLU.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#r75182988"></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.  There are really two separate concerns in the comments you made; I'll address them in reverse order:\r\n\r\nI agree that a `-m` option would be a nice idea, since the number of options for these neighbor searching programs we have are exploding as we add so many types of trees and types of search!  Unfortunately we will have some reverse compatibility to contend with, but it should not be a huge issue, just annoying.\r\n\r\nOnto the other issue, allowing the user to specify some options at query time can provide functionality we don't otherwise have: for instance, the user can specify a query tree with a different leaf size, and more importantly, a user can train a model (i.e. build a reference tree) once, and then use that saved model to do both single-tree and dual-tree search.  This can save a lot of time, for instance if the tree took a long time to build (which is often the case with cover trees).  This is also true of the epsilon parameter---I can do nearest neighbor search with a lot of different epsilon levels.\r\n\r\nSo, I guess, the documentation was wrong about what was actually happening before.  A better way to put it would be this:  If `--single_mode`, `--naive`, `--leaf_size`, or `--epsilon` are specified along with `--input_model_file`, then these options will be taken into account for the search.  For `--leaf_size`, the option will only apply to the reference tree.  The new model preferences will not be saved unless `--output_model_file` is specified.\r\n\r\nReally there are two different types of options there; one can be encapsulated by the `--mode` parameter you suggested; the other (`--leaf_size`) is a specific parameter for the query tree.  I am willing to believe that the use-case for different-leaf-size query trees is so niche that nobody is going to do it, and we can force the user to say that if they are going to build a query tree, then it will be built with the same options as the reference tree, and if they don't like that, then they will need to write C++ and build their trees themselves.  But we can't remove the option to allow the user to specify a different search mode.\r\n\r\nIf you prefer, for the second part, we can leave that for a separate issue, leave the code in currently to set `LeafSize()` and the other parameters, and then open another Github issue and we can work that out separately."}],"action":{"name":"View Pull Request","url":"https://github.com/mlpack/mlpack/pull/747/files/fe090ee13c7cad79e2b7eb8b6690628ba3ead1ed#r75182988"}}}</script>