Thank's for seeing the mistake with the coef array. The same mistake was made
with the s_l and s_u:
double[] s_l = x;
double[] s_u = x;
It's now instead
double[] s_l = new double[x.length];
double[] s_u = new double[x.length];
Changing this made the code run in 7.7 s and after adjusting the epsilon value
it runs in 1 s. Having the same setup in my original SLP algorithm, with the
SLP solver I am implementing running in it's own thread, the SimplexSolver
takes only 0.15 s. A very pleasant computation time!
So it seams there is no need to implement lower and upper bound support in
SimplexSolver in order to gain speed, but perhaps in order to make it more user
friendly. Do I close the issue and make a new one or do I edit the description
of the one created?
Alex
9 apr 2013 kl. 10:19 skrev Thomas Neidhart <[email protected]>:
> To improve the speed in your example, you can also adjust the epsilon
> value, e.g. setting it to 1e-3, which leads to the same result with all
> constraints satisfied, takes on my machine 3.5s instead of 6s with the
> default value of 1e-6. But you will have to experiment with this setting to
> get optimal values for your problem.
>
> Thomas
>
>
> On Tue, Apr 9, 2013 at 10:15 AM, Thomas Neidhart
> <[email protected]>wrote:
>
>> Hi Alexander,
>>
>> thanks, but there is a small problem with your constraints:
>>
>> you assign the zeros array to coeff, but this does not copy the array, so
>> the array will be filled with '1's instead of an array with only one '1' at
>> position i.
>>
>> for ( int i = 0; i < s_l.length; i++ ) {
>> double[] coef = zeros;
>> coef[i] = 1;
>> constraints.add( new LinearConstraint( coef, Relationship.GEQ,
>> s_l[i] ) );
>> constraints.add( new LinearConstraint( coef, Relationship.LEQ,
>> s_u[i] ) );
>> }
>>
>> change this to something like:
>>
>> double[] coef = Arrays.copyOf( zeros, zeros.length );
>>
>> Another thing: the lower/upper bounds in this test are for all variable
>> 1/1.
>>
>> Thomas
>>
>>
>>
>> On Tue, Apr 9, 2013 at 9:52 AM, Alexander Sehlström <
>> [email protected]> wrote:
>>
>>> Issue created!
>>>
>>> https://issues.apache.org/jira/browse/MATH-966
>>>
>>>
>>> 9 apr 2013 kl. 08:36 skrev Thomas Neidhart <[email protected]>:
>>>
>>>> On 04/09/2013 08:23 AM, Alexander Sehlström wrote:
>>>>> Thomas,
>>>>>
>>>>> After writing the pice of code you were asking for I found the error;
>>> The max iteration exception was thrown, but swallowed by some part of my
>>> code, hence not showing up. So by increasing from maximum 100 to 1000
>>> iterations the SimplexSolver returns a result.
>>>>>
>>>>> It is quite slow however and do not come near the computation time I
>>> need solving the same problem in Matlab with linprog. Suggestions of other
>>> Apache Commons Math classes that are solving the same type of problems as
>>> the SimplexSolver do are gratefully accepted.
>>>>
>>>> Hi Alexander,
>>>>
>>>> good that your example works. The reason its slow is most likely related
>>>> to your problem setup.
>>>>
>>>> The SimplexSolver currently does not support lower/upper bounds for the
>>>> variables, thus you had to create separate constraints for each variable
>>>> as suggested before. This makes the calculation quite slow I guess, so
>>>> we should add direct support for such bounds (similar to matlab or
>>> octave).
>>>>
>>>> This can be done with the original tableau (see
>>>> http://homepages.rpi.edu/~mitchj/handouts/upperbounds/).
>>>>
>>>> It would be nice to have your example as performance test, so you could
>>>> add a feature request to the issue tracker yourself.
>>>>
>>>> Thomas
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
