[
https://issues.apache.org/jira/browse/MATH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190823#comment-15190823
]
Gilles commented on MATH-1333:
------------------------------
bq. usually works well
;)
It can happen that an algorithm is not appropriate for certain cases.
MATH-631 might be an interesting (but long!) read, as this could be a similar
issue: an implementation's weakness is not detected at the right place, leading
to a result that is in blatant contradiction with the documentation.
bq. I have no problems with adding yet another bandaid
A relatively important point is to be clear about whether the classes implement
a *reference algorithm*. The more so if an "accommodation" is sometimes the
cause for failing in totally unexpected ways.
Whether the implementations are "standard" or not, if it is possible to detect
the root cause of the problem (and prevent such silly behaviour as you have
reported), then IMO it should be appropriately dealt with (raising an exception
that states the limitation of the algorithm, or put the search back on track).
bq. I'm not trying to come off as rude I am just deeply concerned.
You can be, I agree. But hopefully, there will be a lesson drawn from
MATH-631...
Could you please post a message to the "dev" ML?
> 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)
