Glpk basis must be updated manually

[Balazs Dezso]

The basis must be computed before calling glp_simplex(). The [fc9e366e6759] contains a solution, which computes a new basis whenever it is necessary.

[Alpar Juttner]

Replying to deba:

The basis must be computed before calling glp_simplex(). The [fc9e366e6759] contains a solution, which computes a new basis whenever it is necessary.

Could you give some more details please. Is it a bugfix? Or an improvement?

[Balazs Dezso]

It is a bug fix, but it fixes a problem, which could be raised only if we remove basic columns or rows (the slack variable belongs the row is basic) from the LP.

The "Crashing" message came from GLPK, for more detailed reason see the link: ​http://www.mail-archive.com/help-glpk@gnu.org/msg02701.html

I will make a fix, which makes silent the GLPK.

[Balazs Dezso]

Silent glp_adv_basis()

[Balazs Dezso]

The [21148f69b6c7] makes the glpk silent.

[Alpar Juttner]

Replying to deba:

The [21148f69b6c7] makes the glpk silent.

Shouldn't we put this

glp_term_out(false);

line somewhere into the messageLevel() function instead?

Btw. Is there any reason why the messageLevel() function is implemented both in GlpkLp and GlpkMip instead of being implemented in GlpkBase?

[Balazs Dezso]

Replying to alpar:

Replying to deba:

The [21148f69b6c7] makes the glpk silent.

Shouldn't we put this

glp_term_out(false);

line somewhere into the messageLevel() function instead?

I do not think. There are message levels for control the output of the solvers, but it does not control the output of other functions, like

glp_adv_basis(lp, 0);

But, if we switch off the output in the output globally with

glp_term_out(false);

then the solver will not print message independently from message level.

Btw. Is there any reason why the messageLevel() function is implemented both in GlpkLp and GlpkMip instead of being implemented in GlpkBase?

The reason is rather historical. I think, the message levels and the setting functions can be moved to the GlpkBase?.

[Alpar Juttner]

Replying to deba:

But, if we switch off the output in the output globally with

glp_term_out(false);

then the solver will not print message independently from message level.

You probably misunderstood me. I suggested that messageLevel(0) should also imply glp_term_out(false), but higher message levels would use glp_term_out(true)

Isn't it a good idea?

The reason is rather historical. I think, the message levels and the setting functions can be moved to the GlpkBase?.

Let's move it then.

[Balazs Dezso]

Replying to alpar:

Replying to deba:

But, if we switch off the output in the output globally with

glp_term_out(false);

then the solver will not print message independently from message level.

You probably misunderstood me. I suggested that messageLevel(0) should also imply glp_term_out(false), but higher message levels would use glp_term_out(true)

Isn't it a good idea?

It isn't.

  GlpkLp lp1, lp2;
  lp1.messageLevel(GlpkLp::MESSAGE_FULL_OUTPUT);
  lp2.messageLevel(GlpkLp::MESSAGE_NO_OUTPUT);

The reason is rather historical. I think, the message levels and the setting functions can be moved to the GlpkBase?.

Let's move it then.

Ok, but I would like to this under other ticket, namely I would like to make message handler function for all solvers under #9.

[Alpar Juttner]

Replying to deba:

Replying to alpar:

Replying to deba:

But, if we switch off the output in the output globally with

glp_term_out(false);

then the solver will not print message independently from message level.

You probably misunderstood me. I suggested that messageLevel(0) should also imply glp_term_out(false), but higher message levels would use glp_term_out(true)

Isn't it a good idea?

It isn't.

I see. This is a global setting. Still it could be done in a way that messageLevel() would set a flag and you use that flag to set glp_term_out() when call glp_adv_basis(). It works, unless we use GLPK in two threads.

Btw. is that possible to use GLPK paralelly? Is GLPK thread safe?

Anyway, making glp_adv_basis() completely silent is acceptable.

[Alpar Juttner]

The changesets are in the main branch now, but with changed commit logs and rebased to the tip. See [7ab97e2a0c33] and [e7017ec2d5cd].