DEP: deprecate fallback to sklearn after onedal in LogReg

[samir-nasibli]

Description

deprecate fallback to sklearn after onedal in LogReg. There is no need for this in LogRegression estimator.

---

Checklist to comply with before moving PR from draft:

PR completeness and readability

• I have reviewed my changes thoroughly before submitting this pull request.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation to reflect the changes or created a separate PR with update and provided its number in the description, if necessary.
• Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
• I have added a respective label(s) to PR if I have a permission for that.
• I have resolved any merge conflicts that might occur with the base branch.

Testing

• The unit tests pass successfully.
• I have run it locally and tested the changes extensively.

Performance

• I have measured performance for affected algorithms using scikit-learn_bench and provided at least summary table with measured data, if performance change is expected.
• I have provided justification why performance has changed or why changes are not expected.

[samir-nasibli]

/intelci: run

[samir-nasibli]

@icfaust @ethanglaser @md-shafiul-alam @avolkov-intel @Alexsandruss Dear reviewers this PR pretty ready for the review and merge. Please take a look

[ethanglaser]

Could you provide some additional context? I am not familiar with the original conditional

[avolkov-intel]

What is the need for the removal? We have some places in oneDAL Log Reg implementation where we throw exceptions. We haven't observed such exceptions before but they potentially might happen. I think it is better to keep such fallback to ensure user will get the result computed.

[icfaust]

What is the need for the removal? We have some places in oneDAL Log Reg implementation where we throw exceptions. We haven't observed such exceptions before but they potentially might happen. I think it is better to keep such fallback to ensure user will get the result computed.

So far I see that the logistic Regression itself throws errors on malformed inputs (not sufficient in my opinion for the fallback). However, it also depends on the lapack and logloss/blas implementations (which use GEMV) which may also throw errors. If we don't expect errors to be thrown from logloss then the PR can move forward, otherwise I agree with @avolkov-intel that the PR should be closed.

[icfaust]

@avolkov-intel @samir-nasibli status on this discussion?

[samir-nasibli]

@avolkov-intel @samir-nasibli status on this discussion?

I don't see any reason why we should not go forward, we are not expecting specific failures for LogRegression.

Even more if we are expecting some failures this kind of flows should be controlled by config params. So probably for LinReg (here #1907) make sense add to into config_contex params sklearn_after_onedal, smth like this.

[samir-nasibli]

/intelci: run

[samir-nasibli]

What is the need for the removal? We have some places in oneDAL Log Reg implementation where we throw exceptions. We haven't observed such exceptions before but they potentially might happen. I think it is better to keep such fallback to ensure user will get the result computed.

If we have some exceptions, so it is better to catch them and investigate. Exact cases should be properly dispatched, not after onedal backend. So this reason it make sense to remove it here. At least for Log Reg it is safe, both of CIs are green. So I strongly prefer to go with changes.

[Alexsandruss]

LogisticRegression is less faulty than Linear but common approach for all algorithms with runtime errors is required before making any changes. I guess PCA is applicable here too.

[samir-nasibli]

LogisticRegression is less faulty than Linear but common approach for all algorithms with runtime errors is required before making any changes. I guess PCA is applicable here too.

I will combine these changes with #1907 and bring common solution

[samir-nasibli]

Closing this PR. Please follow proposals on #1907