Re: [Help-glpk] GNU - wish list

[Andrew Makhorin]

>Just a few of wishes
>-  Please bring the glp_write_mps functionality to the new interface
>(which is much better than the old one)

glp_write_mps() will appear in the next subversion of GLPK. However
if you wouldn't like to be waiting for, please tell me and I'll send
you the code via e-mail.

>-  make the code reentrant

This is fundamental issue :+) I agree that reenterability is useful
property, but it requires a special programming technique (due to C).
The standard solution is to gather all static data to one huge struct
allocated dynamically and pass a pointer to this struct to every
routine, but I'd like to avoid such implementation, because it involves
an undesirable interference between heterogenous routines and data
structures. (The other approach is to use C++ and derive all classes
from one "root" class, but from my point of view this is even worse
than to pass a pointer.) I decline to a thought to use local structs
for this purpose, pointers to which are passed implicitly and therefore
transparently for the programmer (i.e. like pseudo registers in some
assembly languages). An appropriate place to keep such pointers is
a thread (process, task, ...) control block maintained by operating
system. However this approach requires resolving issues related to
ANSI C, which doesn't provide such features, and portability between
different operating systems.

In any case it seems to me that for numerical methods reenterability
is not a thing of the top importance, or I am mistaken?

>- since GLPK is designed to be called by other programs, provide the
>ability to use a callback routine that would receive solution status
>information and other messages instead of writing those to stdout and
>stderr.

All output from GLPK routines is performed by three routines: fault(),
error(), and print(). So, if the user wish to redirect output, he can
replace these routines by his own ones. (Probably, it'd more covenient
to make these routines "virtual" that would allow replacing them at the
run-time.)

>- and of course improve stability and speed (!)...  GLPK it is still
>a long way behind other commercial and academic codes.

If you use different optimization packages, could you please report any
benchmark information to compare other packages with GLPK? Although the
latter can't compet with many to-day optimizers, it would help to see
where GLPK needs to be improved first of all.

Best regards,

Andrew Makhorin