[
https://issues.apache.org/jira/browse/MATH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190404#comment-15190404
]
Connor Petty commented on MATH-1333:
------------------------------------
So it looks like MullerSolver was failing due to the solution being right next
to one of the the bracketing values.
The strict test for sequential ordering of x0,x1, and x2 causes problems when
x1==x2.
I have a fix for that particular problem in MullerSolver but the bounds issue
for MullerSolver2 is an entirely different issue.
After analysis it looks like MullerSolver2's lack of bracketing backfires on it
spectacularly as shown in BrokenMuller2.java.
According to the documentation:
{noformat}
Because the interval may not be bracketing, the bisection alternative is
not applicable here. However in practice our treatment usually works
well, especially near real zeroes where the imaginary part of the complex
approximation is often negligible.
{noformat}
The keywords are _usually works well_. It seems that MullerSolver2 has known
limitations to it's algorithm and IMO it looks like a bunch of bandaids applied
to a flawed design. I have no problems with adding yet another bandaid but I
just want to know your opinion on the subject and the history behind that class.
PS. I'm not trying to come off as rude I am just deeply concerned.
> MullerSolver returns value that is out of bounds
> ------------------------------------------------
>
> Key: MATH-1333
> URL: https://issues.apache.org/jira/browse/MATH-1333
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.6
> Reporter: Connor Petty
> Attachments: BrokenMuller.java, BrokenMuller2.java
>
>
> Not sure what went wrong here but in a bracket of [20,100] I got back -19.9!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
