[Bug-glpk] Re: feature request : a softer handling of NaNs

[Andrew Makhorin]

Hi Robbie,

Thank you for the bug report.

> I provided GLPK with a IEEE 754 (quiet) NaN as a
> program-generated constraint.  Opps!
> 
> GLPK duly reported (correctly because nan
> comparison always fails):
> 
>   GLPK Simplex Optimizer, v4.45
>   11 rows, 6 columns, 16 non-zeros
>   Preprocessing...
>   Assertion failed: p->lb < p->ub
>   Error detected in file glpnpp03.c at line 894
> 
> and then promptly killed my application with exit 134.
> 
> Clearly, the problem lies with my client code.  And it
> is really that code that should check for nans.
> 
> But also, perhaps, GLPK could report faulty data and
> return fail instead.
> 
> I don't have a strong view on this feature request,
> because it is, in the first instance, a client-side
> problem.  But is would kinder for GLPK not to fail an
> assert from clearly faulty but arguably still legal input.
> 
> My environment is Ubuntu 10.04 Linux 2.6.32 / Intel
> Core i5 / g++ 4.4.3 / GLPK 4.45 / Boost 1.45.0.
> 

Glpk does not allow non-finite floating-point data (i.e. inf's and
nan's). In particular, to specify that a row/column has no lower/upper
bounds you need to use the types GLP_FR, GLP_LO, or GLP_UP, in which
case corresponding floating-point value will not be used and will not
cause an error. In any case non-finite numbers are not allowed in the
constraint matrix and objective row.

However, it would be reasonable to include checks in some api routines
to detect non-finite values and provide appropriate error messages.
(Please note that glpk is written in ANSI C 89, where functions like
fpclassify are not available.)


Andrew Makhorin