[Coin-discuss] comments, MPS I/O routines

[John J Forrest]

>            There's an odd asymmetry at the OsiSolverInterface (OSI)
level. For
>reading, there's a single function,
>  virtual int OSI::readMps (const char *filename,
>                                        const char *extension = "mps")
const = 0
>
>For writing, there are two,
>  virtual void OSI::writeMps (const char *filename,
>                                          const char *extension = "mps")
const = >0
>and
>  int OSI::writeMps(const char *filename,
>                            const char ** rowNames, const char **
columnNames,
>                            int formatType=0,int numberAcross=2) const ;
>
>Is this asymmetry intentional?

Yes.  An input function should take as wide a range of formats as possible.
readMPS really reads in free format with some fixes to support some
oddities of standard MPS format.  So it should accept standard format +
high precision + (when I write it) an IEEE binary type format.  It also
does not care if the names are genuine or fake and will accept one or two
row names per image.

For writeMPS, the user may want more control and may want real names which
are not supported in Osi.  Hence the two formats.  If/once names go into
Osi then we could do a more complicated virtual interface where solvers
could ignore options they do not understand.

>            What's the plan for compressed format read/write support?
Right now,
>there's no program level control --- the only way to turn it on or off is
at
>compile time. Are we moving to require this of all solver interfaces?
Should
>it be under programmatic control? Perhaps an option in a CMI object?

readMps will read from either - it tests for .gz.  We could do same for
writeMps and we could also allow bzlib as well as zlib.

>            Various other random questions/observations:
>
>  * Seems like there should be a CMI::setProblemName routine.

>  * Is formatType intended to be used as a bit vector, or are the various
>    options mutually exclusive?  I've looked over usage in the code and am
>    still uncertain.

Yes we probably need to be able to set more - objective name etc.  There is
not much incentive as long as these are not in Osi.  What do people think.

formatType was not meant to be a bit vector (I know this is highly unusual
in my coding! it comes from years of saving space when coding onto paper
tape :-)

John Forrest