[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: Andrew Makhorin
Subject: Re: [Bug-glpk] Different generated model on ARMv7 and x86-64
Date: Sun, 06 Aug 2017 18:52:56 +0300

> 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.

Please note that the MathProg translator does not evaluate all members
of model parameters at once; instead that it evaluates only those
members which are actually used in other expressions. For example,

param pt{T} := ceil(1000 * Uniform01());

is not evaluated for all t in T at once; pt[t] is evaluated for a
particular t only if it is actually used in other expressions. So, in
some circumstances pt[t] might be evaluated in different orders and
simultaneously with evaluation of xt and yt members that might affect
the order in which Uniform01() is evaluated.

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

Thus, I think there is no bug in the model generation.

Best regards,

Andrew Makhorin

> > 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
> objective.
> Best regards
> Heinrich Schuchardt

reply via email to

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