[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Updating glpk binding to GLPK 4.15
From: |
address@hidden |
Subject: |
Re: Updating glpk binding to GLPK 4.15 |
Date: |
Mon, 19 Feb 2007 02:08:24 -0800 (PST) |
And is anything known about binding to lp_solve?
Octave 2.9.9 says "not implemented yet"
However, in their sourseforge download page there is already something
related to Octave
https://sourceforge.net/project/showfiles.php?group_id=145213&package_id=159735
And: is it possible to avoid 2 (it seems to me) very unconvinient things (as
far as I saw in Python wrapper):
1) replace maximizing (default) by minimizing
2) avoid default lb=[0 0 0 ... 0]?
Thank you in advance for your responce,
Dmitrey
Rafael Laboissiere wrote:
>
> GLPK 4.15 has been released on February 18. The code is essentially the
> same as in 4.14, the difference being that this new version has libtool
> support and can generate shared libraries.
>
> Anyway, __glpk__.cc was already broken for 4.14, as it has already been
> posted in this mailing list ten days ago. The reasons for the failure
> are:
>
> 1) Neither lib_set_print_hook (or lib_print_hook) nor lib_set_fault_hook
> (or
> lib_fault_hook) are part of the official API.
>
> 2) The macro "insist" is not available anymore (it is defined in the
> header
> file glplib.h, which is no more installed by GLPK in the standard
> place).
>
> 3) The function lib_env_ptr is not part of the API anymore. Besides, it
> accesses the LIBENV structure (which is not part of the API neither).
> Even worse, the code in __glpk__.cc tries to access the mem_tpeak
> member
> of LIBENV, which is a structure, by casting it to a double, which is
> impossible.
>
> I discussed these issues with Andrew Makhorin, the author of GLPK, and he
> suggested the patch attached below, which I am currently applying to the
> Debian package. Notice that this patch will not work for versions of GLPK
> prior to 4.14. To limit Octave to this version or later, the test in
> configure.in should be changed to check only for _glp_lpx_simplex.
>
> Andrew told me that he will implement a workaround to avoid the direct
> call
> to the _glp_lib_print_hook and _glp_lib_fault_hook functions, which are
> private but accessible from libglpk.so. Also, notice that the value
> returned in EXTRA.mem is always zero. I do not now whether it will be
> possible to access, through the public API, the amount of used memory in
> the
> future.
>
> --
> Rafael
>
>
--
View this message in context:
http://www.nabble.com/Updating-glpk-binding-to-GLPK-4.15-tf3250570.html#a9039748
Sent from the Octave - Maintainers mailing list archive at Nabble.com.