[ https://issues.apache.org/jira/browse/MATH808?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=13416436#comment13416436
]
Thomas Neidhart edited comment on MATH808 at 7/17/12 6:42 PM:

I further looked into the test case and finally was able to run it (create Algorithm interface
myself and use MathArrays.distance to compute the euclidean distance).
Imho, the bug report is wrong, as the failing tests are due to an invalid result validation:
{noformat}
1. First equation set q(r) + QL >= 0 <> QL >= q(r) verifications:
1: 0.0000*t + 1.0940*0.0592 + 1.8101*0.0000 + 2.7621*0.0000 + 2.1166*0.0674 + 3.5084*0.3067
+ 2.1122*0.0919 + 1.2818*0.2595 >= 1.8101 <> 1.81011188 >= 1.81011200
EXCEPTION: Wrong equation
java.lang.Exception: Wrong equation
at ru.hse.cst.algorithm.InputOrientedDEAAlgorithm.findEntityOptimum(InputOrientedDEAAlgorithm.java:378)
{noformat}
Actually this is based on the following check:
{noformat}
if(sum < 0) {
throw new Exception("Wrong equation");
}
{noformat}
Now, the SimplexSolver is not a perfect algorithm and has to cope with the usual limitations
of floatingpoint arithmetic. So the solution will only be accurate within a given epsilon.
The default one is 1e6, so the result has to be evaluated taking this epsilon into account:
{noformat}
if(Precision.compareTo(sum, 0, 1e6) < 0){
throw new Exception("Wrong equation");
}
{noformat}
With such a check the test cases run through successfully. I still encountered some "No feasible
solution found" and "Max count exceeded" situations, which I have not further debugged and
are most likely happening because of test setup (the coefficients are created randomly).
was (Author: tn):
I further looked into the test case and finally was able to run it (create Algorithm interface
myself and use MathArrays.distance to compute the euclidean distance).
Imho, the bug report is wrong, as the failing tests are due to an invalid result validation:
{noformat}
1. First equation set q(r) + QL >= 0 <> QL >= q(r) verifications:
1: 0.0000*t + 1.0940*0.0592 + 1.8101*0.0000 + 2.7621*0.0000 + 2.1166*0.0674 + 3.5084*0.3067
+ 2.1122*0.0919 + 1.2818*0.2595 >= 1.8101 <> 1.81011188 >= 1.81011200
EXCEPTION: Wrong equation
java.lang.Exception: Wrong equation
at ru.hse.cst.algorithm.InputOrientedDEAAlgorithm.findEntityOptimum(InputOrientedDEAAlgorithm.java:378)
{noformat}
Actually this is based on the following check:
{noformat}
if(sum < 0) {
throw new Exception("Wrong equation");
}
{noformat}
No, the SimplexSolver is not a perfect algorithm and has to cope with the usual limitations
of floatingpoint arithmetic. So the solution will only be accurate within a given epsilon.
The default one is 1e6, so the result has to be evaluated taking this epsilon into account:
{noformat}
if(Precision.compareTo(sum, 0, 1e6) < 0){
throw new Exception("Wrong equation");
}
{noformat}
With such a check the test cases run through successfully. I still encountered some "No feasible
solution found" and "Max count exceeded" situations, which I have not further debugged and
are most likely happening because of test setup (the coefficients are created randomly).
> SimplexSolver returns values out of constraints bounds
> 
>
> Key: MATH808
> URL: https://issues.apache.org/jira/browse/MATH808
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.0
> Environment: win7 64, eclipse 3.7, Apache Math 3.0
> Reporter: Alexey Slepov
> Assignee: Thomas Neidhart
> Labels: SimplexSolver, constraints, math, unexpected
> Fix For: 3.1
>
> Attachments: InputOrientedDEAAlgorithm.java, InputOrientedDEAAlgorithmTest.java,
InputOrientedDEAAlgorithm_12630_153252.test.txt
>
>
> SimplexSolver gives back result that doesn't match constraints

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
