Re: [Help-glpk] how to restrict variables under 1e-3

Em sex, 26 de out de 2018 às 05:38, Antti Lehtila <address@hidden> escreveu:

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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/help-glpk
_______________________________________________
Help-glpk mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/help-glpk
--

Thiago H. Neves
(31) 98608-0666

_______________________________________________
Help-glpk mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/help-glpk

From:	Thiago Neves
Subject:	Re: [Help-glpk] how to restrict variables under 1e-3
Date:	Fri, 26 Oct 2018 08:02:15 -0300