You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Volkan Aktas (JIRA)" <ji...@apache.org> on 2010/02/25 15:37:27 UTC

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

    [ 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.