Talip7/scikit-learn-issues-multilabel huggingface dataset:
Survey: Open-Source Documentation for Newcomers

### Describe the issue linked to the documentation

Hello Scikit-learn Community!

We are researchers from George Mason University in the United States, looking for open-source contributors to participate in our survey on open-source software (OSS) project documentation use when onboarding. If you are 18 or older and contributed to an OSS project in the last one year, you can help!

The objective of our research is to better understand what type of documentation in OSS projects is more helpful for project newcomers. The survey will take approximately 10 minutes, and upon successful completion of the survey, you will be able to participate in a draw for a chance to win one of four Amazon.com gift cards worth $50 via email.

The link to survey: https://go.gmu.edu/Onboarding_Study

We would be greatly appreciative if you would be willing to participate in this study and help us improve the effectiveness of the onboarding to software projects.

If this message would best be directed or reposted somewhere, please let us know, and we will be happy to modify/repost it.

Thank you for considering participating in our research study!

Research Team: Nursena Kurubas, Dr. Kevin Moran and Dr. Brittany Johnson

IRBNet #: 2029296-1

### Suggest a potential alternative/fix

_No response_

COMMENT:
Yes, thank you!

On Tue, Mar 19, 2024 at 7:31 AM Abdulaziz Aloqeely ***@***.***>
wrote:

> Just checking in, can this be closed now?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/scikit-learn/scikit-learn/issues/27493#issuecomment-2006940451>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AG7OF5JDZIAYGRA7FBCUP2DYZAOYLAVCNFSM6AAAAAA5LNIRZ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBWHE2DANBVGE>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>

Labels: Documentation, good first issue, help wanted
Survey: Open-Source Documentation for Newcomers

### Describe the issue linked to the documentation

Hello Scikit-learn Community!

We are researchers from George Mason University in the United States, looking for open-source contributors to participate in our survey on open-source software (OSS) project documentation use when onboarding. If you are 18 or older and contributed to an OSS project in the last one year, you can help!

The objective of our research is to better understand what type of documentation in OSS projects is more helpful for project newcomers. The survey will take approximately 10 minutes, and upon successful completion of the survey, you will be able to participate in a draw for a chance to win one of four Amazon.com gift cards worth $50 via email.

The link to survey: https://go.gmu.edu/Onboarding_Study

We would be greatly appreciative if you would be willing to participate in this study and help us improve the effectiveness of the onboarding to software projects.

If this message would best be directed or reposted somewhere, please let us know, and we will be happy to modify/repost it.

Thank you for considering participating in our research study!

Research Team: Nursena Kurubas, Dr. Kevin Moran and Dr. Brittany Johnson

IRBNet #: 2029296-1

### Suggest a potential alternative/fix

_No response_

COMMENT:
cc: @adrinjalali

Labels: Documentation, good first issue, help wanted
Allow LogisticRegression with lbfgs solver to control `maxfun` parameter of solver

### Describe the workflow you want to enable

Similarly to what is mentioned on https://github.com/scikit-learn/scikit-learn/issues/9273

> Training an MLP regressor (or classifier) using l-bfgs currently cannot run for more than (approx) 15000 iterations.
This artificial limit is caused by the call site to l-bfgs passing the MLP argument value "max_iters" to the argument for "maxfun" (maximum number of function calls), but not for "maxiter" (maximum number of iterations), so that no matter how large a number you pass as "max_iters" to train for MLP, the iterations are capped by the default value for maxiter (15000).

training a LogisticRegression regressor using l-bfgs currently cannot perform more than (approx) 15000 **function evaluations**.
This artificial limit is caused by the call site to l-bfgs passing the `LogisticRegression` argument value `max_iters` to the argument for `maxiter` (maximum number of iterations), but not for `maxfun` (maximum number of function evaluations), so that no matter how large a number you pass as "max_iters" to train for LogisticRegression, the function evaluations are capped by the default value for maxiter (15000, defined on https://github.com/scipy/scipy/blob/bf776169c753fff655200dc15ae26db95a083b02/scipy/optimize/_lbfgsb_py.py#L212).



### Describe your proposed solution

When calling the l-bfgs solver, set `maxfun` to be the same as `maxiter`, allow the user to control it.

As stated on [#9274](https://github.com/scikit-learn/scikit-learn/pull/9274) by @daniel-perry,
> Ideally you would want to pass in both a 'max_iter' and 'max_fun' argument to MLP, however 'max_fun' doesn't make sense for anything but l-bfgs, so using 'max_iter' to control both seems a reasonable compromise.

The same rational could be used here.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
starting to work on this features

Labels: Enhancement, API, Needs Decision
Allow LogisticRegression with lbfgs solver to control `maxfun` parameter of solver

### Describe the workflow you want to enable

Similarly to what is mentioned on https://github.com/scikit-learn/scikit-learn/issues/9273

> Training an MLP regressor (or classifier) using l-bfgs currently cannot run for more than (approx) 15000 iterations.
This artificial limit is caused by the call site to l-bfgs passing the MLP argument value "max_iters" to the argument for "maxfun" (maximum number of function calls), but not for "maxiter" (maximum number of iterations), so that no matter how large a number you pass as "max_iters" to train for MLP, the iterations are capped by the default value for maxiter (15000).

training a LogisticRegression regressor using l-bfgs currently cannot perform more than (approx) 15000 **function evaluations**.
This artificial limit is caused by the call site to l-bfgs passing the `LogisticRegression` argument value `max_iters` to the argument for `maxiter` (maximum number of iterations), but not for `maxfun` (maximum number of function evaluations), so that no matter how large a number you pass as "max_iters" to train for LogisticRegression, the function evaluations are capped by the default value for maxiter (15000, defined on https://github.com/scipy/scipy/blob/bf776169c753fff655200dc15ae26db95a083b02/scipy/optimize/_lbfgsb_py.py#L212).



### Describe your proposed solution

When calling the l-bfgs solver, set `maxfun` to be the same as `maxiter`, allow the user to control it.

As stated on [#9274](https://github.com/scikit-learn/scikit-learn/pull/9274) by @daniel-perry,
> Ideally you would want to pass in both a 'max_iter' and 'max_fun' argument to MLP, however 'max_fun' doesn't make sense for anything but l-bfgs, so using 'max_iter' to control both seems a reasonable compromise.

The same rational could be used here.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
please share me the closest piece of code to your problem statement

Labels: Enhancement, API, Needs Decision
Allow LogisticRegression with lbfgs solver to control `maxfun` parameter of solver

### Describe the workflow you want to enable

Similarly to what is mentioned on https://github.com/scikit-learn/scikit-learn/issues/9273

> Training an MLP regressor (or classifier) using l-bfgs currently cannot run for more than (approx) 15000 iterations.
This artificial limit is caused by the call site to l-bfgs passing the MLP argument value "max_iters" to the argument for "maxfun" (maximum number of function calls), but not for "maxiter" (maximum number of iterations), so that no matter how large a number you pass as "max_iters" to train for MLP, the iterations are capped by the default value for maxiter (15000).

training a LogisticRegression regressor using l-bfgs currently cannot perform more than (approx) 15000 **function evaluations**.
This artificial limit is caused by the call site to l-bfgs passing the `LogisticRegression` argument value `max_iters` to the argument for `maxiter` (maximum number of iterations), but not for `maxfun` (maximum number of function evaluations), so that no matter how large a number you pass as "max_iters" to train for LogisticRegression, the function evaluations are capped by the default value for maxiter (15000, defined on https://github.com/scipy/scipy/blob/bf776169c753fff655200dc15ae26db95a083b02/scipy/optimize/_lbfgsb_py.py#L212).



### Describe your proposed solution

When calling the l-bfgs solver, set `maxfun` to be the same as `maxiter`, allow the user to control it.

As stated on [#9274](https://github.com/scikit-learn/scikit-learn/pull/9274) by @daniel-perry,
> Ideally you would want to pass in both a 'max_iter' and 'max_fun' argument to MLP, however 'max_fun' doesn't make sense for anything but l-bfgs, so using 'max_iter' to control both seems a reasonable compromise.

The same rational could be used here.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
@lorentzenchr @ogrisel I assume that it would make sense to be able to control these low-level parameters sometimes. I am bit skeptical to add yet another parameter because it will be solver dependent. However, it could be handy to have a generic parameter to pass additional parameters, that could specific to the underlying solver.

Do you have any thoughts on this?

Labels: Enhancement, API, Needs Decision
Allow LogisticRegression with lbfgs solver to control `maxfun` parameter of solver

### Describe the workflow you want to enable

Similarly to what is mentioned on https://github.com/scikit-learn/scikit-learn/issues/9273

> Training an MLP regressor (or classifier) using l-bfgs currently cannot run for more than (approx) 15000 iterations.
This artificial limit is caused by the call site to l-bfgs passing the MLP argument value "max_iters" to the argument for "maxfun" (maximum number of function calls), but not for "maxiter" (maximum number of iterations), so that no matter how large a number you pass as "max_iters" to train for MLP, the iterations are capped by the default value for maxiter (15000).

training a LogisticRegression regressor using l-bfgs currently cannot perform more than (approx) 15000 **function evaluations**.
This artificial limit is caused by the call site to l-bfgs passing the `LogisticRegression` argument value `max_iters` to the argument for `maxiter` (maximum number of iterations), but not for `maxfun` (maximum number of function evaluations), so that no matter how large a number you pass as "max_iters" to train for LogisticRegression, the function evaluations are capped by the default value for maxiter (15000, defined on https://github.com/scipy/scipy/blob/bf776169c753fff655200dc15ae26db95a083b02/scipy/optimize/_lbfgsb_py.py#L212).



### Describe your proposed solution

When calling the l-bfgs solver, set `maxfun` to be the same as `maxiter`, allow the user to control it.

As stated on [#9274](https://github.com/scikit-learn/scikit-learn/pull/9274) by @daniel-perry,
> Ideally you would want to pass in both a 'max_iter' and 'max_fun' argument to MLP, however 'max_fun' doesn't make sense for anything but l-bfgs, so using 'max_iter' to control both seems a reasonable compromise.

The same rational could be used here.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
Could we please first merge #26721 (needs a 2nd reviewer) and then see if we still need control over `maxfun`. I'm not opposed to it, just first things first.

Labels: Enhancement, API, Needs Decision
Allow LogisticRegression with lbfgs solver to control `maxfun` parameter of solver

### Describe the workflow you want to enable

Similarly to what is mentioned on https://github.com/scikit-learn/scikit-learn/issues/9273

> Training an MLP regressor (or classifier) using l-bfgs currently cannot run for more than (approx) 15000 iterations.
This artificial limit is caused by the call site to l-bfgs passing the MLP argument value "max_iters" to the argument for "maxfun" (maximum number of function calls), but not for "maxiter" (maximum number of iterations), so that no matter how large a number you pass as "max_iters" to train for MLP, the iterations are capped by the default value for maxiter (15000).

training a LogisticRegression regressor using l-bfgs currently cannot perform more than (approx) 15000 **function evaluations**.
This artificial limit is caused by the call site to l-bfgs passing the `LogisticRegression` argument value `max_iters` to the argument for `maxiter` (maximum number of iterations), but not for `maxfun` (maximum number of function evaluations), so that no matter how large a number you pass as "max_iters" to train for LogisticRegression, the function evaluations are capped by the default value for maxiter (15000, defined on https://github.com/scipy/scipy/blob/bf776169c753fff655200dc15ae26db95a083b02/scipy/optimize/_lbfgsb_py.py#L212).



### Describe your proposed solution

When calling the l-bfgs solver, set `maxfun` to be the same as `maxiter`, allow the user to control it.

As stated on [#9274](https://github.com/scikit-learn/scikit-learn/pull/9274) by @daniel-perry,
> Ideally you would want to pass in both a 'max_iter' and 'max_fun' argument to MLP, however 'max_fun' doesn't make sense for anything but l-bfgs, so using 'max_iter' to control both seems a reasonable compromise.

The same rational could be used here.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
@lorentzenchr I'll review today.

Labels: Enhancement, API, Needs Decision
Allow LogisticRegression with lbfgs solver to control `maxfun` parameter of solver

### Describe the workflow you want to enable

Similarly to what is mentioned on https://github.com/scikit-learn/scikit-learn/issues/9273

> Training an MLP regressor (or classifier) using l-bfgs currently cannot run for more than (approx) 15000 iterations.
This artificial limit is caused by the call site to l-bfgs passing the MLP argument value "max_iters" to the argument for "maxfun" (maximum number of function calls), but not for "maxiter" (maximum number of iterations), so that no matter how large a number you pass as "max_iters" to train for MLP, the iterations are capped by the default value for maxiter (15000).

training a LogisticRegression regressor using l-bfgs currently cannot perform more than (approx) 15000 **function evaluations**.
This artificial limit is caused by the call site to l-bfgs passing the `LogisticRegression` argument value `max_iters` to the argument for `maxiter` (maximum number of iterations), but not for `maxfun` (maximum number of function evaluations), so that no matter how large a number you pass as "max_iters" to train for LogisticRegression, the function evaluations are capped by the default value for maxiter (15000, defined on https://github.com/scipy/scipy/blob/bf776169c753fff655200dc15ae26db95a083b02/scipy/optimize/_lbfgsb_py.py#L212).



### Describe your proposed solution

When calling the l-bfgs solver, set `maxfun` to be the same as `maxiter`, allow the user to control it.

As stated on [#9274](https://github.com/scikit-learn/scikit-learn/pull/9274) by @daniel-perry,
> Ideally you would want to pass in both a 'max_iter' and 'max_fun' argument to MLP, however 'max_fun' doesn't make sense for anything but l-bfgs, so using 'max_iter' to control both seems a reasonable compromise.

The same rational could be used here.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
@vascosmota Could you provide a minimal example?

Labels: Enhancement, API, Needs Decision
Allow LogisticRegression with lbfgs solver to control `maxfun` parameter of solver

### Describe the workflow you want to enable

Similarly to what is mentioned on https://github.com/scikit-learn/scikit-learn/issues/9273

> Training an MLP regressor (or classifier) using l-bfgs currently cannot run for more than (approx) 15000 iterations.
This artificial limit is caused by the call site to l-bfgs passing the MLP argument value "max_iters" to the argument for "maxfun" (maximum number of function calls), but not for "maxiter" (maximum number of iterations), so that no matter how large a number you pass as "max_iters" to train for MLP, the iterations are capped by the default value for maxiter (15000).

training a LogisticRegression regressor using l-bfgs currently cannot perform more than (approx) 15000 **function evaluations**.
This artificial limit is caused by the call site to l-bfgs passing the `LogisticRegression` argument value `max_iters` to the argument for `maxiter` (maximum number of iterations), but not for `maxfun` (maximum number of function evaluations), so that no matter how large a number you pass as "max_iters" to train for LogisticRegression, the function evaluations are capped by the default value for maxiter (15000, defined on https://github.com/scipy/scipy/blob/bf776169c753fff655200dc15ae26db95a083b02/scipy/optimize/_lbfgsb_py.py#L212).



### Describe your proposed solution

When calling the l-bfgs solver, set `maxfun` to be the same as `maxiter`, allow the user to control it.

As stated on [#9274](https://github.com/scikit-learn/scikit-learn/pull/9274) by @daniel-perry,
> Ideally you would want to pass in both a 'max_iter' and 'max_fun' argument to MLP, however 'max_fun' doesn't make sense for anything but l-bfgs, so using 'max_iter' to control both seems a reasonable compromise.

The same rational could be used here.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
I am working on creating a minimal example, but it is proving harder than expected. I will update as soon as I have one.

Labels: Enhancement, API, Needs Decision
Allow LogisticRegression with lbfgs solver to control `maxfun` parameter of solver

### Describe the workflow you want to enable

Similarly to what is mentioned on https://github.com/scikit-learn/scikit-learn/issues/9273

> Training an MLP regressor (or classifier) using l-bfgs currently cannot run for more than (approx) 15000 iterations.
This artificial limit is caused by the call site to l-bfgs passing the MLP argument value "max_iters" to the argument for "maxfun" (maximum number of function calls), but not for "maxiter" (maximum number of iterations), so that no matter how large a number you pass as "max_iters" to train for MLP, the iterations are capped by the default value for maxiter (15000).

training a LogisticRegression regressor using l-bfgs currently cannot perform more than (approx) 15000 **function evaluations**.
This artificial limit is caused by the call site to l-bfgs passing the `LogisticRegression` argument value `max_iters` to the argument for `maxiter` (maximum number of iterations), but not for `maxfun` (maximum number of function evaluations), so that no matter how large a number you pass as "max_iters" to train for LogisticRegression, the function evaluations are capped by the default value for maxiter (15000, defined on https://github.com/scipy/scipy/blob/bf776169c753fff655200dc15ae26db95a083b02/scipy/optimize/_lbfgsb_py.py#L212).



### Describe your proposed solution

When calling the l-bfgs solver, set `maxfun` to be the same as `maxiter`, allow the user to control it.

As stated on [#9274](https://github.com/scikit-learn/scikit-learn/pull/9274) by @daniel-perry,
> Ideally you would want to pass in both a 'max_iter' and 'max_fun' argument to MLP, however 'max_fun' doesn't make sense for anything but l-bfgs, so using 'max_iter' to control both seems a reasonable compromise.

The same rational could be used here.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
+1 for this as I stumbled over a case where I need to set a higher `maxfun`.

Labels: Enhancement, API, Needs Decision
Allow LogisticRegression with lbfgs solver to control `maxfun` parameter of solver

### Describe the workflow you want to enable

Similarly to what is mentioned on https://github.com/scikit-learn/scikit-learn/issues/9273

> Training an MLP regressor (or classifier) using l-bfgs currently cannot run for more than (approx) 15000 iterations.
This artificial limit is caused by the call site to l-bfgs passing the MLP argument value "max_iters" to the argument for "maxfun" (maximum number of function calls), but not for "maxiter" (maximum number of iterations), so that no matter how large a number you pass as "max_iters" to train for MLP, the iterations are capped by the default value for maxiter (15000).

training a LogisticRegression regressor using l-bfgs currently cannot perform more than (approx) 15000 **function evaluations**.
This artificial limit is caused by the call site to l-bfgs passing the `LogisticRegression` argument value `max_iters` to the argument for `maxiter` (maximum number of iterations), but not for `maxfun` (maximum number of function evaluations), so that no matter how large a number you pass as "max_iters" to train for LogisticRegression, the function evaluations are capped by the default value for maxiter (15000, defined on https://github.com/scipy/scipy/blob/bf776169c753fff655200dc15ae26db95a083b02/scipy/optimize/_lbfgsb_py.py#L212).



### Describe your proposed solution

When calling the l-bfgs solver, set `maxfun` to be the same as `maxiter`, allow the user to control it.

As stated on [#9274](https://github.com/scikit-learn/scikit-learn/pull/9274) by @daniel-perry,
> Ideally you would want to pass in both a 'max_iter' and 'max_fun' argument to MLP, however 'max_fun' doesn't make sense for anything but l-bfgs, so using 'max_iter' to control both seems a reasonable compromise.

The same rational could be used here.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
The question is a bit: Should we add a `maxfun` parameter to estimators using lbfgs, or should be add a `solver_options` argument?

Labels: Enhancement, API, Needs Decision