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 _______________________________________________ Bug-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-glpk
