Hi Heinrich, Thank you for your help.
> The following model is sufficient to demonstrate it: > > param xt := Uniform01(); > param pt := Uniform01(); > > var y, >= 0; > minimize obj : y + pt + xt; > > solve; > > printf "%f ", pt; > printf "%f\n", xt; > end; > > > > 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(); > > 0.128311804030091 > 0.009596675168723 > Good news: there is no bug. In the first two cases evaluation of pt precedes evaluation of xt while in the last three cases xt is evaluated before pt. At the moment I cannot say why this happens, however, this is obviously not a bug, because the order of evaluation of subexpressions is not defined (like in C). Thus, if evaluation of a subexpression has a side effect (as in case of using Uniform01), the result is indeterminate. Best regards, Andrew Makhorin _______________________________________________ Bug-glpk mailing list Bug-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/bug-glpk