-
Notifications
You must be signed in to change notification settings - Fork 225
FIX: Prevent log probabilities from turning to infinite #3315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIX: Prevent log probabilities from turning to infinite #3315
Conversation
CI job for sklearnex requires this PR to be merged in order to pass: |
/intelci: run |
1 similar comment
/intelci: run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Segfault appears in the Pre-Commit:
Fatal Python error: Segmentation fault
__release_lnx/daal4py-3.12/daal4py/mb/logistic_regression_builders.py", line 169 in predict_log_proba
sources/tests/test_model_builders.py::test_logreg_builder[2-True-False]
/intelci: run |
I am unable to reproduce any segfault locally. Tried also running with asan and valgrind under different compilers, and didn't see any reported memory issues. |
I was able to reproduce the issue on the same machine where the CI error was reported. It appears to be an issue of not checking for null pointers or error codes somwhere, most likely on the daal4py side:
Doesn't appear to be related to the changes here though. Will investigate further. |
Will need to merge this PR before in order for the CI jobs to pass: |
/intelci: run |
/intelci: run |
bd4dce3
into
uxlfoundation:main
Description
This PR adds the same fix as in #3293 for the prediction function that outputs log probabilities, so that sklearnex's
predict_log_proba
doesn't end up returning infinites.PR should start as a draft, then move to ready for review state after CI is passed and all applicable checkboxes are closed.
This approach ensures that reviewers don't spend extra time asking for regular requirements.
You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way.
For example, PR with docs update doesn't require checkboxes for performance while PR with any change in actual code should have checkboxes and justify how this code change is expected to affect performance (or justification should be self-evident).
Checklist to comply with before moving PR from draft:
PR completeness and readability
Testing