Re: [Help-glpk] Slow performance on "Select minimum" task

[Jan van Rijn]

I'm not sure if that is entirely the case.

The way I interpreted your solution was that 'at least one y-value per column will be >= 1'.

I don't see exactly which constraint makes sure that there will be exactly one y-value per column 1

(which, again, we don't need if all values in M are >= 0).

If M contains negative values, it could be that:

* an ideal solution would have multiple y-values per column bigger than zero, and

* These values will not necessarily be one, but can take even higher values (due to this GLPK gave an error message, and this is how I found out)

Sorry if I am missing something obvious.

The current solution seems to work like a charm so thanks again :)

Best,

Jan

2018-06-06 10:06 GMT-04:00 Michael Hennebry <address@hidden>:

On Tue, 5 Jun 2018, Jan van Rijn wrote:

2018-06-05 23:39 GMT-04:00 Michael Hennebry <address@hiddenu>
:

On Tue, 5 Jun 2018, Jan van Rijn wrote:

- M[r,c] should contain positive values (which guarantees that y[r,c] == 1

iff x[r] - SUM x[s] == 1)

I'm pretty sure that is not necessary.
the y's depend only on the x's and the order of the M values.
In any case, I think the zeros in your original problem
will not be much of an issue.

I should rephrase: The array should contain values >= zero.
(negative values are an issue, but these can be scaled away easily. )

I'm not sure where that is coming from.
The y's are determined by the x's and by sets
of rows determined by the order of the M values, not their signs.
Only one y value in a column can be one.

--
Michael   address@hiddenedu
"Sorry but your password must contain an uppercase letter, a number,
a haiku, a gang sign, a heiroglyph, and the blood of a virgin."
                                                             --  someeecards