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 > [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
