On 08/06/2017 05:52 PM, Andrew Makhorin wrote:
>> The important thing is that I observed a difference for model parameters.
>> ./glpsol --wlp test.lp -m test.mod --check
>> yields totally different files test.lp and different objective values.
>> So this is a problem in model generation.
>> If I take one of the lp files as input I get the same objective value on
>> both platforms. There is no problem in the solver.
>> Replacing Uniform01() by round(Uniform01(), 5) does not change the
>> output for parameter pt[50] on both platforms.
>> By rounding you cannot explain the difference between 334 and 472 of
>> model parameter pt[50]. This could only be explained by the sequence of
>> generation steps and hence Uniform01() values assigned to different
>> parameters on the different platforms.
>> This should be fixed.
> Could you please isolate the possible bug? That is, reduce your model
> file to a minimum minimorum where the bug still appears.

The problem already exists in GLPK 4.53.

The following model is sufficient to demonstrate it:

param xt := Uniform01();
param pt := Uniform01();

var y, >= 0;
minimize obj : y + pt + xt;


printf "%f ", pt;
printf "%f\n", xt;

x86: (32-bit LSB executable, i686, gcc 4.9.2)
0.009597 0.128312

x86-64: (64-bit LSB, x86-64, gcc 6.3.0)
0.009597 0.128312

armv7 (32-bit LSB, ARM, gcc 6.3.0)
0.128312 0.009597

armv8 (64-bit LSB, ARM aarch64, gcc 6.4.0)
0.128312 0.009597

mips (ELF 32-bit MSB, gcc 4.9.2)
0.128312 0.009597

Random numbers are generated in this sequence on all architectures:

printf {1..2} "%16.15f\n", Uniform01();


Best regards

Heinrich Schuchardt

Bug-glpk mailing list

Reply via email to