[PPL-devel] [Fink-devel] ppl-0.10.2 check thorough test fail

[Enea Zaffanella]

Il 01/04/2011 18:45, David Fang ha scritto:
>> Il 29/03/2011 02:39, David Fang ha scritto:
>>> Hello,
>>>     With ppl-0.10.2, several Mac OS X fink users (including myself) have
>>> observed the following single test failure on 10.5 and 10.6, using
>>> Apple's gcc-4.2, arch i686-apple-darwin{9,10}, with thorough tests
>>> enabled:
>>>
>>> /usr/bin/grep -E "^Optimum value: "
>>> ../../../demos/ppl_lpsol/expected_mpz
>>>> expected_optima && /usr/bin/grep -E "^Optimum value: " obtained
>>>> obtained_optima && diff -u expected_optima obtained_optima
>>> --- expected_optima     2011-03-22 21:05:58.000000000 -0400
>>> +++ obtained_optima     2011-03-22 21:05:58.000000000 -0400
>>> @@ -1,9 +1,10 @@
>>> -Optimum value: -3
>>> -Optimum value: 2
>>> +Optimum value: -2
>>> +Optimum value: 1
>>
>> I agree with Roberto that all of the symptoms suggest that Apple gcc-4.2
>> is miscompiling something (and we would really appreciate if someone can
>> try out using a newer gcc).
>>
>> The first differences above are related to a very simple MIP problem
>> test. Can you please provide us with the output of the following command:
>>
>> $ cd <PATH_TO_PPL_BUILD>/demos/ppl_lpsol
>> $ ./ppl_lpsol -s -p1 -v 4 -c -M
>> <PATH_TO_PPL_SRC>/demos/ppl_lpsol/examples/ex1.mps
>>
>> This will also show the problem as read from the input, which should be
>> something like:
>> =============
>> Integer variables:
>> x1 x2
>> Constraints:
>> -2*x1 - x2 >= -5
>> 4*x1 - 4*x2 >= -5
>> x1 >= 0
>> x2 >= 0
>> Objective function:
>> x1 - 2*x2
>> Maximizing.
>> =============
> 
> Hi,
>     On 10.6/i686, apple-gcc-4.2, gmp-5.0.1, I get:
> 
> fang at fangbook 4> ./ppl_lpsol -s -p1 -v 4 -c -M
> ../../../demos/ppl_lpsol/examples/ex1.mps
> Integer variables:
> x1 x2
> Constraints:
> -2*x1 - x2 >= -5
> 4*x1 - 4*x2 >= -5
> x1 >= 0
> -x1 >= -1
> x2 >= 0
> -x2 >= -1
> Objective function:
> x1 - 2*x2
> Maximizing.
> Optimum value: 1
> Optimum location:
> x1 = 1
> x2 = 0
> 
> Different indeed!  Does this indicate an earlier parse error?
> 
> Fang


Well ... ppl_lpsol uses glpk to parse the input file.
Apparently, the installed glpk is parsing the input file differently.
Which version of glpk do you have?

If I am to guess, I would say that the installed glpk is flagging the
two variables as being *binary* variables, rather than *integer* ones.
But this is just a guess, I will have to check the documentation for the
input file format as well as the changelog for glpk.

Apart from this, ppl_lpsol seems to be correctly doing its job in
optimizing the problem (and use of option -c seems to confirm that glpk
is computing the very same optimal value).

Enea.