Ok, so is it correct to say that it doesn't matter how close these solvers
match the original algorithm as long as the differences between the
original and our implementation are well documented?
I should also note that the bracketing behavior in MullerSolver is not part
of the original algorithm nor is some of MullerSolver2's erroneous state
recovery logic (for handling complex roots and straight lines). Now, it
would be fair to say that MullerSolver2 is a more "pure" implementation of
Muller's method since the original Muller's method never used bracketing.
Given that bracketing is not part of the original Muller's Method, would
that also mean that in our Muller's Method implementation it should
completely reasonable (and in some cases expected) for the implementation
to return values outside of the original bracket?
Or is it our goal to make sure that all solver implementations always
return a value within the bracket even if it means changing the original
algorithm to support bracketing?
I'm assuming that the latter is preferred since the bracketing behavior is
expected by users.
Best Regards,
Connor Petty
On Fri, Mar 11, 2016 at 6:34 PM, Gilles <gilles@harfang.homelinux.org>
wrote:
> Hi.
>
> On Fri, 11 Mar 2016 17:50:59 0800, Connor Petty wrote:
>
>> I've been doing some investigation regarding MATH1333 and I cam across
>> some bounds issues in MullerSolver and MullerSolver2. There are a few test
>> cases I've created which cause these solvers to return values outside of
>> their initial bracket. I've created fixes for MullerSolver but
>> MullerSolver2 baffles me. MullerSolver is more or less an implementation
>> of
>> the algorithm you can find at
>> https://en.wikipedia.org/wiki/Muller's_method
>> while MullerSolver2 is an implementation of the algorithm at
>> http://mathworld.wolfram.com/MullersMethod.html. But the major difference
>> between MullerSolver 1 & 2 is that MullerSolver2 was designed to work
>> without bracketing. This turns out to make it fairly easy to make it
>> return
>> faulty values.
>>
>> Now my question is: How much should these solvers stick to their original
>> algorithms?
>>
>
> Fully.
> Or the name and documentation of the class must clearly reflect that
> it is a variation.
>
> If the original algorithm is flawed should solver exhibit those
>> same flaws?
>>
>
> Yes (if the flaw is in the algorithm itself, not just in the
> implementation,
> e.g. because the expected properties assume infinite precision).
>
> But whenever possible the implementation should (_must_, IMHO) check that
> it has not hit one of its own limitation, and "fail early".
>
> There is some precedent for that in SecantSolver which has the same
>> guarantees of convergence as the original algorithm (which has none).
>> But MullerSolver2 is clearly a patched version of the algorithm
>>
>
> Do you have the possibility to check another implementation of that
> algorithm?
> Since the Javadoc says that the original deals with complex values but CM
> avoids it, I wonder whether this could be the problem.
>
> it is based
>> off of and exhibits some very characteristic flaws from the original
>> algorithm. Should MullerSolver2's bounds issue be fixed or should that
>> issue just be accepted a limitation of that algorithm?
>>
>
> Cf. above.
>
> Best regards,
> Gilles
>
>
>> Best Regards,
>> Connor Petty
>>
>
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>
>
