<p dir="auto">In the subject line function, log probability is calculated as follows (lines 287-88):</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="proba[proba &lt;= 0] = 1e-5
log_proba = np.log(proba)"><pre class="notranslate"><code class="notranslate">proba[proba &lt;= 0] = 1e-5
log_proba = np.log(proba)
</code></pre></div>
<p dir="auto">Oftentimes one encounters probabilities significantly smaller than 1.0e-5 that are still nonzero. In the current implementation, for example, the log prob of 1.0e-6 will actually evaluate higher than log prob of 0.0. It seems to me that a better implementation of this would be a floor-like function as follows:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="proba[proba &lt; 1e-9] = 1.e-9"><pre class="notranslate"><code class="notranslate">proba[proba &lt; 1e-9] = 1.e-9
</code></pre></div>
<p dir="auto">This is an issue that I am opening for discussion.</p>
<p dir="auto"><strong>Problem</strong>:</p>
<p dir="auto">Sample weights (in various estimators), group labels (for cross-validation objects), group id (in learning to rank) are optional information that need to be passed to estimators and the CV framework, and that need to kept to the proper shape throughout the data processing pipeline.</p>
<p dir="auto">Right now, the code to deal with this is inhomogeneous in the codebase, the APIs are not fully consistent (ie passing sample_weights to objects that do not support them will just crash).</p>
<p dir="auto">This discussion attempt to address the problems above, and open the door to more flexibility to future evolution</p>
<p dir="auto"><strong>Core idea</strong></p>
<p dir="auto">We could have an argument that is a dataframe-like object, ie a collection (dictionary) of 1D array-like object. This argument would be sliced and diced by any code that modifies the number of samples (CV objects, train_test_split), and passed along the data.</p>
<p dir="auto"><strong>Proposal A</strong></p>
<p dir="auto">All objects could take as a signature fit(X, y, sample_props=None), with y optional for unsupervised learners.</p>
<p dir="auto">sample_props (name to be debated) would be a dataframe like object (ie either a dict of arrays, or a dataframe). It would have a few predefined fields, such as "weight" for sample weight, "group" for sample groups used in cross validation. It would open the door to attaching domain-specific information to samples, and thus make scikit-learn easier to adapt to specific applications.</p>
<p dir="auto"><strong>Proposal B</strong></p>
<p dir="auto">y could be optionally a dataframe-like object, which would have as a compulsory field "target", serving the purpose of the current y, and other fields such as "weight", "group"... In which case, arguments "sample_weights" and alike would disappear into it.</p>
<p dir="auto">People at the Paris sprint (including me) seem to lean towards proposal A.</p>
<p dir="auto"><strong>Implementation aspects</strong></p>
<p dir="auto">The different validation tools will have to be adapted to accept this type of argument. We should not depend on pandas. Thus we will accept dict of arrays (and build a helper function to slice them in the sample direction). Also, this helper should probably accept data frame (but given that data frames can be indexed like dictionaries, this will not be a problem.</p>
<p dir="auto">Finally, the CV objects should be adapted to split the corresponding structure. Probably in a follow up to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="58896940" data-permission-text="Title is private" data-url="https://github.com/scikit-learn/scikit-learn/issues/4294" data-hovercard-type="pull_request" data-hovercard-url="/scikit-learn/scikit-learn/pull/4294/hovercard" href="https://github.com/scikit-learn/scikit-learn/pull/4294">#4294</a></p>