[jira] Created: (MATH-347) Brent solver shouldn't need strict ordering of min, max and initial

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (MATH-347) Brent solver shouldn't need strict ordering of min, max and initial

ASF GitHub Bot (Jira)
Brent solver shouldn't need strict ordering of min, max and initial
-------------------------------------------------------------------

                 Key: MATH-347
                 URL: https://issues.apache.org/jira/browse/MATH-347
             Project: Commons Math
          Issue Type: Bug
    Affects Versions: 2.0
            Reporter: Volkan Aktas


The "solve(final UnivariateRealFunction f, final double min, final double max, final double initial)" function calls verifySequence() which enforces a strict ordering of min, max and initial parameters. I can't see why that is necessary - the rest of solve() seems to be able to handle "initial == min" and "initial == min" cases just fine. In fact, the JavaDoc suggests setting initial to min when not known but that is not possible at the moment.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (MATH-347) Brent solver shouldn't need strict ordering of min, max and initial

ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/MATH-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838356#action_12838356 ]

Volkan Aktas commented on MATH-347:
-----------------------------------

Also would like to add that when this constraint is removed it should be possible to make the "solve(final UnivariateRealFunction f, final double min, final double max)" call the other solve() function without any additional logic.
 


> Brent solver shouldn't need strict ordering of min, max and initial
> -------------------------------------------------------------------
>
>                 Key: MATH-347
>                 URL: https://issues.apache.org/jira/browse/MATH-347
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Volkan Aktas
>
> The "solve(final UnivariateRealFunction f, final double min, final double max, final double initial)" function calls verifySequence() which enforces a strict ordering of min, max and initial parameters. I can't see why that is necessary - the rest of solve() seems to be able to handle "initial == min" and "initial == min" cases just fine. In fact, the JavaDoc suggests setting initial to min when not known but that is not possible at the moment.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (MATH-347) Brent solver shouldn't need strict ordering of min, max and initial

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/MATH-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luc Maisonobe resolved MATH-347.
--------------------------------

    Resolution: Fixed

Fixed in subversion repository as of r917668.
Thanks for reporting the issue

> Brent solver shouldn't need strict ordering of min, max and initial
> -------------------------------------------------------------------
>
>                 Key: MATH-347
>                 URL: https://issues.apache.org/jira/browse/MATH-347
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Volkan Aktas
>
> The "solve(final UnivariateRealFunction f, final double min, final double max, final double initial)" function calls verifySequence() which enforces a strict ordering of min, max and initial parameters. I can't see why that is necessary - the rest of solve() seems to be able to handle "initial == min" and "initial == min" cases just fine. In fact, the JavaDoc suggests setting initial to min when not known but that is not possible at the moment.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Closed: (MATH-347) Brent solver shouldn't need strict ordering of min, max and initial

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/MATH-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Phil Steitz closed MATH-347.
----------------------------


> Brent solver shouldn't need strict ordering of min, max and initial
> -------------------------------------------------------------------
>
>                 Key: MATH-347
>                 URL: https://issues.apache.org/jira/browse/MATH-347
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Volkan Aktas
>
> The "solve(final UnivariateRealFunction f, final double min, final double max, final double initial)" function calls verifySequence() which enforces a strict ordering of min, max and initial parameters. I can't see why that is necessary - the rest of solve() seems to be able to handle "initial == min" and "initial == min" cases just fine. In fact, the JavaDoc suggests setting initial to min when not known but that is not possible at the moment.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.