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

Ted Ralphs tkralphs at lehigh.edu
Wed May 30 18:49:23 EDT 2007


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.

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.

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.

Cheers,

Ted
-- 
Dr. Ted Ralphs
Associate Professor
Industrial and Systems Engineering
Lehigh University
(610)758-4784
tkralphs at lehigh.edu
www.lehigh.edu/~tkr2


More information about the Cgl mailing list