[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-glpk] Different generated model on ARMv7 and x86-64

From: Heinrich Schuchardt
Subject: Re: [Bug-glpk] Different generated model on ARMv7 and x86-64
Date: Sun, 6 Aug 2017 15:20:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 08/06/2017 01:51 PM, Andrew Makhorin wrote:
> Hi Heinrich,
>> the appended file test.mod is examples/threads/clustering.mod with
>> appended line
>> printf {t in T} "%d -> %d\n", t,  pt[t];
>> Essentially the line prints out part of the generated problem.
>> The output on x86-64 ends with:
>> 49 -> 608
>> 50 -> 334
>> Model has been successfully processed
>> The output on ARMv7 ends with:
>> 49 -> 852
>> 50 -> 472
>> Model has been successfully processed
>> How can it be that the generated model differs depending on the CPU
>> architecture?
> I think this is due to round-off errors, because you are using
> floating-point computations in your model.

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.

With the appended rnd.mod no difference occurs between x86-64 and armv7.

> Please conduct the following experiment: move the statement
> printf {t in T} "%d -> %d\n", t,  pt[t];

In this case I get the same results on both platforms but different to
the original values. This is expected because we changed the sequence in
which Uniform01() is called for the different parameters.

So the error must be in the code generating the constraints and the

Best regards

Heinrich Schuchardt

Attachment: rnd.csv
Description: Text Data

Attachment: rnd.mod
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]