The code uses the avl tree to make a priority queue, and only cares about
the relative ordering of the nodes. As a matter of fact, in this specific
use having duplicate keys is expected and actually quite common. The
pre-existing GLPK implementation of AVL trees works fine in this case, as I
never
Hello Chris !
Thank you for reply !
Please commit your "probing" code to a new branch in your repository,
this way maybe someone can give you some help polishing it.
Also about the problem with "avl_tree" do you plan to review and fix
your repository ?
Cheers !
On 26/9/20 17:30, Chris
A brief description of the changes is in
https://lists.gnu.org/archive/html/help-glpk/2018-02/msg00018.html - those
considerably increased the number of miplib problems that can be solved, in
particular using pseudocost branching. Do ask if you have any specific
questions, but it was some time ago
Forwarded Message
From: Jeffrey Kantor
To: Chris Matrakidis
Cc: Domingo Alvarez Duarte , help-glpk@gnu.org
Subject: Re: Solver performance solving examples/life_goe.mod
Date: Sat, 26 Sep 2020 10:23:18 -0400
> Will there be a point where the GLPK package will be opened for
>
Hello Chris !
Thank you for reply !
Can you describe in a few lines what your improvements achieved ?
I've been looking at your changes and found that you've bitten by
"src/env/avl.c" avl_tree do not reject duplicate keys but do not provide
a way to recover duplicates, I fixed this here
I made some performance improving patches a few years ago. You can find
them in: https://github.com/cmatraki/GLPK
Best Regards,
Chris Matrakidis
On Sat, 26 Sep 2020 at 14:54, Domingo Alvarez Duarte
wrote:
> Hello !
>
> Testing GLPK I left it solving examples/lie_goe.mod for more than 2
>
Hello !
Activating glp_long_double one by one I found that the ones that really
makes hashi.mod with "--cuts" perform better are the ones bellow (but
doing so degrades performance for anything else).
=
/***
*
On Sat, 2020-09-26 at 09:51 +0200, Manuel Muñoz Márquez wrote:
> > Why do you want glpk to produce absolutely identical results on
> > different platforms? This has no practical sense.
> >
>
> I think this is a desirable behavior. If your are solving a real
> problem it look very weird if you
On Sat, 2020-09-26 at 13:54 +0200, Domingo Alvarez Duarte wrote:
> Hello !
>
> Testing GLPK I left it solving examples/lie_goe.mod for more than 2
> hours and it didn't found a solution (wasm and native) then I stopped
> then and tried with cplex/gurobi/xpress/scip all of then gives a
>
Hello Michael !
I did a revision of the usage of "glp_long_double" see here
https://github.com/mingodad/GLPK/commit/4941d1633e52b802bdc5f102715ac3db25db5245
Revised usage of glp_long_double, now it does solve hashi.mod and
tiling.mod faster with "--cuts" option but hashi.mod without
>Why do you want glpk to produce absolutely identical results on
> different platforms? This has no practical sense.
>
I think this is a desirable behavior. If your are solving a real
problem it look very weird if you provides a solution using your
computer and when you put in the user web
11 matches
Mail list logo
