Minibex: semantics of comma-separated variables

[goldsztejn-a]

With the following minibex file

Variables
	y1,y2,y3 in [0,1];

Minimize y1+y2+y3;

Constraints
    y1<=1;y2<=1;y3<=1;
end

the output is meaning less:

 possibly unbounded objective (f*=-oo)

 f* in	[-inf,-1.79769313486e+308]
	(best bound)

 x* =	(-1.79769313486e+308 ; -3262036970 ; 0)
	(best feasible point)

 relative precision on f*:	nan
 absolute precision on f*:	inf
 cpu time used:			0.0708890000001s
 number of cells:		2266

If we add constraints in addition to lower bounds

Constraints
    y1>=0;y2>=0;y3>=0;
    y1<=1;y2<=1;y3<=1;
end

then the out put is correct

 optimization successful!

 f* in	[0,1.48219693753e-323]
	(best bound)

 x* =	(4.94065645842e-324 ; 4.94065645842e-324 ; 4.94065645842e-324)
	(best feasible point)

 relative precision on f*:	inf
 absolute precision on f*:	1.48219693753e-323 [passed] 
 cpu time used:			0.775439000001s
 number of cells:		6472

However, I expected this linear problem is solved in one iteration, while 6472 cells are generated.

[gchabert]

Alexandre,
This is because the interval restriction in your Minibex file only applies to the last variable.
If you write instead:

Variables
	y1 in [0,1];
	y2 in [0,1];
	y3 in [0,1];

Minimize y1+y2+y3;

Then you get the expected answer.

[gchabert]

About the number of cells in your second example: I think the main reason is that the constraint y3>=0 you have added is redundant with the bound constraint y3 in [0,1] which creates a singularity in the certification.
If you just remove y3>=0 the number of cells boils down to only 90.

[goldsztejn-a]

This is all very clear, thanks !

Does it make sense to update minibex so that the domain applies to all variables in the line, or is there a reason why it is this way?

If yes, we can try to do that in Nantes.

[gchabert]

Does it make sense to update minibex so that the domain applies to all variables in the line, or is there a reason why it is this way?

No, you're right. So far, in variable declaration, the comma separator just acts as a semicolon, which is misleading.
One expects the domain to apply to all variables in this case. I will fix this.

[gchabert]

Ok, I made the fix and all tests pass.
However there is a consequence.
Now a comma-separated list of variables all share the same domain, the one of the last. For consistency, this forbids declaration like:

x in [0,1], y in [0,2]

But there are benchmarks which use this type of declaration (ex: I5.bch).
So one should make a pass on all the benches to fix the syntax (i.e., replace the "," by a "';").

[goldsztejn-a]

super merci !

[gchabert]

En fait, je réouvre cette issue parce qu'il faudrait a minima rajouter un warning lorsque l'utilisateur utilise cette manière de déclarer les variables.
Le dernier exemple que je donnais n'était pas trop gênant en soi, parce que le parsing du fichier échoue: l'utilisateur est averti qu'il y a un changement de syntaxe avec la nouvelle version d'ibex. Mais si quelqu'un a un fichier minibex du même style que celui que tu as écrit, ex:

Variables
	x, y in [0,1];

il obtiendra un résultat différent suivant la version d'ibex qu'il utilise; ça pose un problème de rétro-compatibilité.
Bref, il aurait fallu adopter cette convention dès le départ, mais le "mal est fait" en quelque sorte...