> Something doesn't match for me, because I'm compiling GLPK/glpsol
> with and without optmization and get the same reported cuts:
>
> Cuts on level 0: gmi = 5; mir = 44; cov = 20; clq = 3; !! *
> the same
> =
> Cuts on level 0: gmi = 5; mir = 44; cov = 20; clq = 3; *
> the
Hello Andrew !
Something doesn't match for me, because I'm compiling GLPK/glpsol with
and without optmization and get the same reported cuts:
Compiled with "-O3 -DNDEBUG"
=
glpsol2 --cuts -m hashi.mod
GLPSOL: GLPK LP/MIP Solver, v4.65
Parameter(s) specified in the command line:
--cuts
Hello Mike !
I did changed in several places see here
https://github.com/mingodad/GLPK/commit/b370a854be0c10c06e025896dedc4e3461278497
===
Changed some declarations to glp_long_double in hope that using it on
mainly "sums" would improve performance/accuracy, but right now
performance
On Fri, 2020-09-25 at 10:04 +0200, Domingo Alvarez Duarte wrote:
> Hello Michael !
>
> Thank you for reply !
>
> I'll take into account the use of possible wider float format for
> intermediary values using something like your suggestion of
> redefinable
> type like "glp_double_t" (actually in
Hello Michael !
Thank you for reply !
I'll take into account the use of possible wider float format for
intermediary values using something like your suggestion of redefinable
type like "glp_double_t" (actually in gcc 9 in linux x86 "double_t" and
"double" are equal).
But also leave the
