[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GLPK interface [was Re: Multithreaded Atlas ...]
From: |
Tatsuro MATSUOKA |
Subject: |
Re: GLPK interface [was Re: Multithreaded Atlas ...] |
Date: |
Tue, 31 Mar 2009 16:26:51 +0900 (JST) |
Hello
I have used glpk 4.36 built myself. No problem was occurred.
octave.exe:21> c = [10, 6, 4]';
octave.exe:22> a = [ 1, 1, 1;
> 10, 4, 5;
> 2, 2, 6];
octave.exe:23> b = [100, 600, 300]';
octave.exe:24> lb = [0, 0, 0]';
octave.exe:25> ub = [];
octave.exe:26> ctype = "UUU";
octave.exe:27> vartype = "CCC";
octave.exe:28> s = -1;
octave.exe:29>
octave.exe:29> param.msglev = 1;
octave.exe:30> param.itlim = 100;
octave.exe:31>
octave.exe:31> [xmin, fmin, status, extra] = ...
> glpk (c, a, b, lb, ub, ctype, vartype, s, param)
xmin =
33.33333
66.66667
0.00000
fmin = 733.33
status = 180
extra =
{
lambda =
3.33333
0.66667
0.00000
redcosts =
0.00000
0.00000
-2.66667
time = 0
mem = 0
}
glpk seemed to work correct without modification of octave code.
Have the codes of octave-3.0.4RC7 been corrected for newer glpk ?
Regards
Tatsuro
--- Marco Atzeri wrote:
>
> --- Lun 30/3/09, Tatsuro MATSUOKA ha scritto:
>
> > Da: Tatsuro MATSUOKA
> > Oggetto: Re: Multithreaded Atlas can be used by GCC-4.3.3-sjlj-mingw-TDM
> > (Was Re: Sjlj vs
> dwarf2 on mingw for octave)
> > A: address@hidden, address@hidden
> > Cc: "MATSUOKA Tatsuro" <address@hidden>
> > Data: Luned 30 marzo 2009, 12:44
> > Hello
> >
>
> > The glpk 4.34 library on Gnuwin 32 cannot be used for my
> > case. Use older version glpk 4.8 on GnuWin32
> > or build the glpk libraries from source by mingw system.
> >
>
> This is due to upstream glpk decision to export only API
> function, see my discussion about it:
> http://lists.gnu.org/archive/html/help-glpk/2009-03/msg00041.html
>
> from glpk src/Makefile.am
> we have:
>
> libglpk_la_LDFLAGS = -version-info 22:0:22 \
> -export-symbols-regex '^(glp_|_glp_lpx_).*'
>
> These are the two functions called by octave
> (if I am not wrong) and both are marked obsolete in glpk
> __glp_lib_fault_hook
> __glp_lib_print_hook
>
> but in the API there is only
> _glp_term_hook (exported)
>
> so probably we need to re-write the interface...
>
> in any case from glplibo4.c and glplibo3.c
> __glp_lib_print_hook is a call to _glp_term_hook
> __glp_lib_fault_hook is just an assert check.
>
> ************************************************************
> void lib_print_hook(int (*func)(void *info, char *buf), void *info)
> { /* (obsolete) */
> #if 0 /* iso c complains */
> int (*hook)(void *, const char *) = (void *)func;
> #else
> int (*hook)(void *, const char *) = (int(*)(void *, const char *))
> (func);
> #endif
> lib_term_hook(hook, info);
> return;
> }
> ***************************************************************
> void lib_fault_hook(int (*func)(void *info, char *buf), void *info)
> { /* (obsolete) */
> xassert(func == func);
> xassert(info == info);
> return;
> }
> ***************************************************************
>
> > Regards
> >
> > Tatsuro
> >
>
> Regards
> Marco
>
>
>
>
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/