Hi, Antti. I was hopeful that I could change the accuracy through glpsol. I'll also try to rescale the inputs in the model to work arround this situation.
Thanks again for the help! Best regards, Thiago Henrique Neves Em sex, 26 de out de 2018 às 05:38, Antti Lehtila <[email protected]> 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 <[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 > -- Thiago H. Neves (31) 98608-0666
_______________________________________________ Help-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-glpk
