[Cgl] (bug) CoinMpsIO / CglMixedIntegerRounding / arbitrary constants

[fmargot at andrew.cmu.edu]

On Wed, 30 May 2007, Ted Ralphs wrote:

> Lou Hafer wrote:
>
>> 	Francois asked me to have a look at why dylp failed to pass the
>> CglMixedIntegerRounding unit test. After a bit of poking, here's the problem:
>>
>>   * CoinMpsIO imposes an arbitrary upper bound of 1e30 on general integer
>>     variables.
>>
>>   * CglMixedIntegerRounding fails to recognise this as infinity, becomes
>>     confused, and generates invalid cuts.
>>
>> If I patch OsiDylp to override 1e30 with the current infinity things work just
>> fine.
>>
>> If it's left to me to fix, I'll remove the arbitrary constant from CoinMpsIO.
>> This might break other pieces of code.  Arguably, code that depends on this
>> arbitrary constant should force it as part of its own setup.
>
> I'm guessing this is part of the MPS standard, so we should find that
> out first. If it is part of the standard, then the question is whether
> we should ignore the standard or come up with a better solution. If you
> change the standard notion of infinity, then you may end up creating MPS
> using this class that cannot be read back in by a reader that adheres to
> the standard. In this case, it seems like the onus is on the person
> reading the MPS file to adhere to the standard.

The failure occur on the file Cgl/trunk/test/CglTestData.capPlan1.mps.
All numbers in the MPS file are smaller than 1e5, but some variables
have no specified upper bound, i.e. they are implicitly +infinity.
I doubt that the MPS standard mandates that an implicit +infinity
upper bound be set to 1e30.

>
> In any case, I'm not sure how you "get rid of the arbitrary upper
> bound," since you need some notion of infinity to create a problem
> description. How else do you define infinity in the absence of external
> input besides pulling an arbitrary large number out of the air? If the
> default value doesn't suffice for your purposes, you can always override
> it with the setDefaultBound() function. The only problem with this is
> that the function won't accept a bound bigger than 1.0e30, which does
> seem a little strange. But then again, the max integer that may be
> defined may also be in the standard. Besides eliminating this
> restriction, I don't see what else to do.
>

There should be a COIN_INFINITY defined somewhere and used everywhere, 
if COIN_DBL_MAX is not appropriate. Any number larger than COIN_INFINITY 
in the input of a code should be treated as infinity by the code.
Right now, CoinPresolveMatrix uses COIN_DBL_MAX as infinity, CoinLpIO 
uses DBL_MAX, Clp uses 1e25 or 1e30 (with sometimes weird things happening 
when bounds are in between), Bcp uses 1e100, and these are only the ones I 
remember. Uniformity might be helpful.

> I guess this discussion should be taking place on the CoinUtils mailing
> list, since this is not a Cgl issue. I've cc'd this message on that list.
>

A Cgl fix of the problem would be to make inifinity a parameter of the
CglMixedInteger generator. Maybe time to kick the CglParam discussion again ...

Francois