Re: how to restrict variables under 1e-3

Hi Thiago,

Yes, I understood that it was a very simple example. Anyway, I
think using variable bounds makes better sense than singleton
rows.

Concerning optimizing solvers in general, when they are based on
floating -point arithmetic, they typically use feasibility and
optimality tolerances for checking whether the current solution is
feasible / optimal. In glpsol, I believe the primal feasibility
tolerance is by default 1e-7, and so you cannot expect accuracy
beyond that.

Indeed, in your second example, I tested setting:

param delta_min default 3.3e-4;

param delta_max default 6.6e-4;

And I am getting the correct solution when using these values:

x.val = 1.089e-07

y.val = 0.00033

delta_min = 0.00033

delta_max = 0.00066

As you can see, x.val is already very close to the feasibility
tolerance.

However, if I set delta_min default 3e-4 and delta_max default
6e-4, the solution has x.val = 0. This is understandable, because
the difference to the correct value is then already below the
feasibility tolerance (3e-4 ^2 = 9e-8). So, this is fully as
expected. You could, of course, reduce the tolerance to have a
higher accuracy, but I think changing it is available only through
the API.

Best wishes,

Antti

----------

On 25.10.2018 22:29, Thiago Neves
wrote:

Hi, Antti.

Thank you very much for the reply.

Your solution works for the example. But, as I said,
this is just a very simple example to ilustrate the
problem. Actually, the real problem is: The statement
"r1" is being violated when it is close to zero.

See this other example:

-----------------

# The params delta_min/delta_max might be set through
.dat file, so it can assume any value.

param delta_min default 1e-4;

param delta_max default 2e-4;

var x >= 0;

# y is different than zero

var y >= delta_min;

r1: x >= delta_min * y;

r2: x <= delta_max * y;

# should result in x == delta_min * y or infeasible

minimize f: x + y;

solve;

# Should result in (x, y) == (delta_min ^ 2, delta_min)

display x;

display y;

display delta_min;

display delta_max;

end;

-----------------

Using the defaults, x should result in delta_min^2, but it
is actually resulting in 0. Maybe this is happening due to a
numerical threshold in the solver.

So, my questions are:

Is there an explanation for this behavior?

Is there a way to setup glpsol to correctly run this model
without using exact arithmetic?

Thanks again for the help!

--

Att,

Thiago Henrique Neves

Em qui, 25 de out de 2018 às 11:39, Antti
Lehtila <[email protected] >
escreveu:

Hi,

I tested with using variable bounds, and it worked well
even with 1e-5 / 2e-5 :

#-------------------------

param delta_min default 1e-5;

param delta_max default 2e-5;

var x >= delta_min, <= delta_max;

minimize f: x;

solve;

#-------------------------

Regards,

AL

----------

On 23.10.2018 19:16, Thiago Neves wrote:

Hi, all!

I need to solve a problem in witch some
statements may restricts a variable above a
small value, e.g. 1e-4. But after solving,
GLPSOL is setting this variable equals to zero.

If I run this problem using "--exact" argument,
it works as expected, but it uses much more
memory. Is there any argument or work arround to
o run this problem in glpsol without using exact
arithimetic?

Example:

In the simple example attached, the minimun
value for "x" must be "delta_min", but in my
tests:

if delta_min < 1e-3, x results in 0 (even for
delta_min = 9.999e-4)

(1) - Using "statement_test_0.0001.dat" file,
the result is wrong:

3 rows, 1 column, 3 non-zeros

Preprocessing...

~ 0: obj = 0.000000000e+000 infeas =
0.000e+000

OPTIMAL SOLUTION FOUND BY LP PREPROCESSOR

Time used: 0.0 secs

Memory used: 0.1 Mb (88615 bytes)

Display statement at line 14

x.val = 0

x = 0.0000000000000000

Display statement at line 17

delta_min = 0.0001

Display statement at line 18

delta_max = 0.0002

Model has been successfully processed

(2) - Using "statement_test_0.001.dat"
file, the result is correct:

3 rows, 1 column, 3 non-zeros

Preprocessing...

~ 0: obj = 1.000000000e-003 infeas =
0.000e+000

OPTIMAL SOLUTION FOUND BY LP PREPROCESSOR

Time used: 0.0 secs

Memory used: 0.1 Mb (88615 bytes)

Display statement at line 14

x.val = 0.001

x = 0.0010000000000000

Display statement at line 17

delta_min = 0.001

Display statement at line 18

delta_max = 0.002

Model has been successfully processed

(3) - Running (1) with "--exact" argument,
the result is correct, but uses more memory:

glp_exact: 3 rows, 1 columns, 3 non-zeros

GLPK bignum module is being used

(Consider installing GNU MP to attain a much better
performance.)

0: infsum = 0.0001 (0)

1: infsum = 0 (0)

* 1: objval = 0.0001 (0)

* 1: objval = 0.0001 (0)

OPTIMAL SOLUTION FOUND

Time used: 0.0 secs

Memory used: 0.1 Mb (92819 bytes)

Display statement at line 14

x.val = 0.0001

x = 0.0001000000000000

Display statement at line 17

delta_min = 0.0001

Display statement at line 18

delta_max = 0.0002

Model has been successfully processed

Thanks for your help!

Att,

Thiago Henrique Neves

--

Thiago H. Neves

(31) 98608-0666

_______________________________________________
Help-glpk mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-glpk

_______________________________________________

Help-glpk mailing list

[email protected]

https://lists.gnu.org/mailman/listinfo/help-glpk

--

Thiago H. Neves

(31) 98608-0666

_______________________________________________
Help-glpk mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-glpk