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
--
Thiago H. Neves
(31) 98608-0666
|