Re: [Help-glpk] Compiling GLPK with stdcall calling convention

2017-01-08 Thread Andrew Makhorin 
On Sun, 2017-01-08 at 23:11 +0100, Heinrich Schuchardt wrote:
> Hello Andrew,
> 
> you refer to a non-existent file glpk_4_61_stdcall.def.

Just checked the tarball (that one I uploaded to sourceforge)--the file 
glpk_4_61_stdcall.def does exist in 'w32' subdirectory.

> I get the same warning concerning make not being cdecl. I think this
> should be fixed.

Do you mean main in examples/glpsol.c ? Okay, I will fix it.

> 
> There are warnings for mcfrelax.c and proxy.c due to conversion of
> double to int.
> In proxy.c this is due to inconsistent variable types for time.

Will fix it.

> In mcfrelax.c variable low is checked to be integer. So you can safely
> prepend (int) to avoid the warnings.

This conforms to ANSI C. Besides, the GNU Coding Standards does not
recommend using cast if the implicit type conversion is sufficient.

> 
> See appended patches.

Thanks.


Best,

Andrew Makhorin


___
Help-glpk mailing list
Help-glpk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-glpk

Re: [Help-glpk] Compiling GLPK with stdcall calling convention

2017-01-08 Thread Heinrich Schuchardt 
Hello Andrew,

you refer to a non-existent file glpk_4_61_stdcall.def.
I get the same warning concerning make not being cdecl. I think this
should be fixed.

There are warnings for mcfrelax.c and proxy.c due to conversion of
double to int.
In proxy.c this is due to inconsistent variable types for time.
In mcfrelax.c variable low is checked to be integer. So you can safely
prepend (int) to avoid the warnings.

See appended patches.

Best regards

Heinrich Schuchardt

On 01/08/2017 06:54 PM, Andrew Makhorin wrote:
> Heinrich,
> 
>>
>> unfortunately you missed one function passed to qsort.
>>
>> Please, apply the appended patch
>> https://github.com/xypron/glpk/commit/f6afa4d6645868b8369c757debe8bc8663ec9c7c
> 
> Please see an updated version ibid.:
> http://sourceforge.net/projects/noumenon/files/tmp/
> (Note that this is *not* an official release.)
> 
> I checked it with VC9 and all seems to work. Please check it with VC10.
> Thanks.
> 
> There was a warning:
> ..\examples\glpsol.c(932) : warning C4007: 'main' : must be '__cdecl'
> However I think this should work because internally main always finishes
> via ExitProcess winapi call rather than via return statement.
> 
> 
> Andrew Makhorin
> 
> 

From 113a56825cb10f1f25ca5948c5105b996fd2c0b4 Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt 
Date: Sun, 8 Jan 2017 21:32:51 +0100
Subject: [PATCH] Fix build errors

- add missing file glpk_4_61_stdcall.def
- glpsol.c: main must be __cdecl

Signed-off-by: Heinrich Schuchardt 
---
 examples/glpsol.c |   8 ++
 w32/glpk_4_61_stdcall.def | 226 ++
 2 files changed, 234 insertions(+)
 create mode 100644 w32/glpk_4_61_stdcall.def

diff --git a/examples/glpsol.c b/examples/glpsol.c
index 9542675..1d6d448 100644
--- a/examples/glpsol.c
+++ b/examples/glpsol.c
@@ -21,6 +21,10 @@
 *  along with GLPK. If not, see .
 ***/
 
+#ifdef HAVE_CONFIG_H
+#include 
+#endif
+
 #include 
 #include 
 #include 
@@ -928,7 +932,11 @@ static int parse_cmdline(struct csa *csa, int argc, char *argv[])
 typedef struct { double rhs, pi; } v_data;
 typedef struct { double low, cap, cost, x; } a_data;
 
+#ifndef __WOE__
 int main(int argc, char *argv[])
+#else
+int __cdecl main(int argc, char *argv[])
+#endif
 { /* stand-alone LP/MIP solver */
   struct csa _csa, *csa = &_csa;
   int ret;
diff --git a/w32/glpk_4_61_stdcall.def b/w32/glpk_4_61_stdcall.def
new file mode 100644
index 000..4fa0ada
--- /dev/null
+++ b/w32/glpk_4_61_stdcall.def
@@ -0,0 +1,226 @@
+LIBRARY glpk_4_61_stdcall
+VERSION 4.61
+DESCRIPTION "GNU Linear Programming Kit"
+EXPORTS
+glp_create_prob
+glp_set_prob_name
+glp_set_obj_name
+glp_set_obj_dir
+glp_add_rows
+glp_add_cols
+glp_set_row_name
+glp_set_col_name
+glp_set_row_bnds
+glp_set_col_bnds
+glp_set_obj_coef
+glp_set_mat_row
+glp_set_mat_col
+glp_load_matrix
+glp_check_dup
+glp_sort_matrix
+glp_del_rows
+glp_del_cols
+glp_copy_prob
+glp_erase_prob
+glp_delete_prob
+glp_get_prob_name
+glp_get_obj_name
+glp_get_obj_dir
+glp_get_num_rows
+glp_get_num_cols
+glp_get_row_name
+glp_get_col_name
+glp_get_row_type
+glp_get_row_lb
+glp_get_row_ub
+glp_get_col_type
+glp_get_col_lb
+glp_get_col_ub
+glp_get_obj_coef
+glp_get_num_nz
+glp_get_mat_row
+glp_get_mat_col
+glp_create_index
+glp_find_row
+glp_find_col
+glp_delete_index
+glp_set_rii
+glp_set_sjj
+glp_get_rii
+glp_get_sjj
+glp_scale_prob
+glp_unscale_prob
+glp_set_row_stat
+glp_set_col_stat
+glp_std_basis
+glp_adv_basis
+glp_cpx_basis
+glp_simplex
+glp_exact
+glp_init_smcp
+glp_get_status
+glp_get_prim_stat
+glp_get_dual_stat
+glp_get_obj_val
+glp_get_row_stat
+glp_get_row_prim
+glp_get_row_dual
+glp_get_col_stat
+glp_get_col_prim
+glp_get_col_dual
+glp_get_unbnd_ray
+glp_get_it_cnt
+glp_set_it_cnt
+glp_interior
+glp_init_iptcp
+glp_ipt_status
+glp_ipt_obj_val
+glp_ipt_row_prim
+glp_ipt_row_dual
+glp_ipt_col_prim
+glp_ipt_col_dual
+glp_set_col_kind
+glp_get_col_kind
+glp_get_num_int
+glp_get_num_bin
+glp_intopt
+glp_init_iocp
+glp_mip_status
+glp_mip_obj_val
+glp_mip_row_val
+glp_mip_col_val
+glp_check_kkt
+glp_print_sol
+glp_read_sol
+glp_write_sol
+glp_print_ranges
+glp_print_ipt
+glp_read_ipt
+glp_write_ipt
+glp_print_mip
+glp_read_mip
+glp_write_mip
+glp_bf_exists
+glp_factorize
+glp_bf_updated
+glp_get_bfcp
+glp_set_bfcp
+glp_get_bhead
+glp_get_row_bind
+glp_get_col_bind
+glp_ftran
+glp_btran
+glp_warm_up
+glp_eval_tab_row
+glp_eval_tab_col
+glp_transform_row
+glp_transform_col
+glp_prim_rtest
+glp_dual_rtest
+glp_analyze_bound
+glp_analyze_coef
+glp_ios_reason
+glp_ios_get_prob
+glp_ios_tree_size
+glp_ios_curr_node
+glp_ios_next_node
+glp_ios_prev_node
+glp_ios_up_node
+glp_ios_node_level
+glp_ios_node_bound
+glp_ios_best_node
+glp_ios_mip_gap
+glp_ios_node_data
+glp_ios_row_attr
+glp_ios_pool_size
+glp_ios_add_row
+glp_ios_del_row
+glp_ios_clear_pool
+glp_ios_can_branch
+glp_ios_branch_upon
+glp_ios_select_n

Re: [Help-glpk] Compiling GLPK with stdcall calling convention

2017-01-08 Thread Andrew Makhorin 
Heinrich,

> 
> unfortunately you missed one function passed to qsort.
> 
> Please, apply the appended patch
> https://github.com/xypron/glpk/commit/f6afa4d6645868b8369c757debe8bc8663ec9c7c

Please see an updated version ibid.:
http://sourceforge.net/projects/noumenon/files/tmp/
(Note that this is *not* an official release.)

I checked it with VC9 and all seems to work. Please check it with VC10.
Thanks.

There was a warning:
..\examples\glpsol.c(932) : warning C4007: 'main' : must be '__cdecl'
However I think this should work because internally main always finishes
via ExitProcess winapi call rather than via return statement.


Andrew Makhorin


___
Help-glpk mailing list
Help-glpk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-glpk

Re: [Help-glpk] Compiling GLPK with stdcall calling convention

2017-01-08 Thread Heinrich Schuchardt 
Hello Andrew,

unfortunately you missed one function passed to qsort.

Please, apply the appended patch
https://github.com/xypron/glpk/commit/f6afa4d6645868b8369c757debe8bc8663ec9c7c

Best regards

Heinrich Schuchardt

On 01/08/2017 04:14 PM, Andrew Makhorin wrote:
> Hi Heinrich,
> 
> Thank you for your efforts.
> 
>> for Windows 32 two different calling conventions are used: __cdecl and
>> __stdcall.
>>
>> To use GLPK in conjunction with 32bit LibreOffice (or OpenOffice) Basic
>> it is necessary to compile the GLPK library with __stdcall.
>>
>> Compilation with __stdcall can be achieved by using the /Gz compiler
>> option for Visual Studio Express C++.
>>
>> Unfortunately this is not enough. All functions passed to qsort must use
>> the __cdecl calling convention.
> 
> I'd like just to know why MSVC developers didn't provide a stdcall
> version of the C lib. 
> 
>>
>> On Github I have set up a repository with a patched GLPK 4.60 which
>> allows both compiling with __cdecl and with __stdcall:
>> https://github.com/xypron/glpk/tree/glpk-4.60-stdcall
>>
>> The essential patch is
>> https://github.com/xypron/glpk/commit/471b8ee233da57391b0f4401380c0405f7ab2455
>>
>> It adds a symbol CDECL that is defined in config.h and applied to the
>> relevant comparison functions.
>>
>> I have also added a Makefile and build batch file but these are not
>> essential.
>>
>> Could you, please, consider adding this CDECL symbol to GLPK 4.61.
> 
> Done. Please see
> http://sourceforge.net/projects/noumenon/files/tmp/
> (Note that this is *not* an official release.)
> 
> To avoid defining some macros (i.e. CDECL) on compiling glpk on a
> platform other than GNU/Linux and MS Windows I made the changes in the
> following way:
> 
> #ifndef __WOE__
> int foo(...
> #else
> int __cdecl foo(...
> #endif
> 
> It is always possible to define __cdecl as an empty token sequence, so
> there should be no problem I hope.
> 
> Please check the package with VC10. (I've got only VC9.)
> 
> 
> Best regards,
> 
> Andrew Makhorin
> 
> 

From f6afa4d6645868b8369c757debe8bc8663ec9c7c Mon Sep 17 00:00:00 2001
From: Heinrich Schuchardt 
Date: Sun, 8 Jan 2017 16:37:27 +0100
Subject: [PATCH 1/1] spychuzc.c: add missing __cdecl

Signed-off-by: Heinrich Schuchardt 
---
 src/simplex/spychuzc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/simplex/spychuzc.c b/src/simplex/spychuzc.c
index 27a4924..e320f8f 100644
--- a/src/simplex/spychuzc.c
+++ b/src/simplex/spychuzc.c
@@ -501,7 +501,11 @@ int spy_ls_eval_bp(SPXLP *lp, const double d[/*1+n-m*/],
 *  On exit the routine also replaces the parameter slope with a new
 *  value that corresponds to the new last break-point bp[num1]. */
 
+#ifndef __WOE__
 static int fcmp(const void *v1, const void *v2)
+#else
+static int __cdecl fcmp(const void *v1, const void *v2)
+#endif
 { const SPYBP *p1 = v1, *p2 = v2;
   if (p1->teta < p2->teta)
  return -1;
-- 
2.11.0

___
Help-glpk mailing list
Help-glpk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-glpk

Re: [Help-glpk] Compiling GLPK with stdcall calling convention

2017-01-08 Thread Heinrich Schuchardt 
Hello Andrew,

thank you for adopting the change. I will now start testing.

I think the stdcall DLL should not be called glpk_4_61.dll.
We could call it glpk_4_61_stdcall.dll instead.
This way the user is sure which calling convention the selected DLL is
using.

When GLPK 4.61 is released I will add the stdcall DLL to GLPK for Windows.

Best regards

Heinrich Schuchardt

On 01/08/2017 04:14 PM, Andrew Makhorin wrote:
> Hi Heinrich,
> 
> Thank you for your efforts.
> 
>> for Windows 32 two different calling conventions are used: __cdecl and
>> __stdcall.
>>
>> To use GLPK in conjunction with 32bit LibreOffice (or OpenOffice) Basic
>> it is necessary to compile the GLPK library with __stdcall.
>>
>> Compilation with __stdcall can be achieved by using the /Gz compiler
>> option for Visual Studio Express C++.
>>
>> Unfortunately this is not enough. All functions passed to qsort must use
>> the __cdecl calling convention.
> 
> I'd like just to know why MSVC developers didn't provide a stdcall
> version of the C lib. 
> 
>>
>> On Github I have set up a repository with a patched GLPK 4.60 which
>> allows both compiling with __cdecl and with __stdcall:
>> https://github.com/xypron/glpk/tree/glpk-4.60-stdcall
>>
>> The essential patch is
>> https://github.com/xypron/glpk/commit/471b8ee233da57391b0f4401380c0405f7ab2455
>>
>> It adds a symbol CDECL that is defined in config.h and applied to the
>> relevant comparison functions.
>>
>> I have also added a Makefile and build batch file but these are not
>> essential.
>>
>> Could you, please, consider adding this CDECL symbol to GLPK 4.61.
> 
> Done. Please see
> http://sourceforge.net/projects/noumenon/files/tmp/
> (Note that this is *not* an official release.)
> 
> To avoid defining some macros (i.e. CDECL) on compiling glpk on a
> platform other than GNU/Linux and MS Windows I made the changes in the
> following way:
> 
> #ifndef __WOE__
> int foo(...
> #else
> int __cdecl foo(...
> #endif
> 
> It is always possible to define __cdecl as an empty token sequence, so
> there should be no problem I hope.
> 
> Please check the package with VC10. (I've got only VC9.)
> 
> 
> Best regards,
> 
> Andrew Makhorin
> 
> 


___
Help-glpk mailing list
Help-glpk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-glpk

[Help-glpk] Patches to improve pseudocost initialisatiion speed

2017-01-08 Thread Chris Matrakidis 
Andrew,

Since you are preparing a new GLPK release, I'm sending you three
patches to consider, that improve the speed of pseudocost
initialization.
The first reuses the same glp_prob in each round to avoid unnecessary
copying, the second introduces a bfd_copy function and the third uses
bfd_copy to avoid recalculating the exact same factorisation in every
simplex call during each initialisation round.
These patches do not affect the execution order of the code, only the
initialisation speed: in all tests I did, I get the exact same number
of nodes and simplex iterations

Best Regards,

Chris Matrakidis
diff --git a/src/glpios09.c b/src/glpios09.c
index d87578c..b9e6b5a 100644
--- a/src/glpios09.c
+++ b/src/glpios09.c
@@ -403,6 +403,8 @@ struct csa
   double *up_sum; /* double up_sum[1+n]; */
   /* up_sum[j] is the sum of per unit degradations of the objective
  over all up_cnt[j] subproblems */
+  glp_prob *work;
+  /* working problem to avoid unnecessary initializations */
 };
 
 void *ios_pcost_init(glp_tree *tree)
@@ -418,24 +420,44 @@ void *ios_pcost_init(glp_tree *tree)
   {  csa->dn_cnt[j] = csa->up_cnt[j] = 0;
  csa->dn_sum[j] = csa->up_sum[j] = 0.0;
   }
+  csa->work = NULL;
   return csa;
 }
 
-static double eval_degrad(glp_prob *P, int j, double bnd)
+static double eval_degrad(glp_tree *T, int j, double bnd)
 { /* compute degradation of the objective on fixing x[j] at given
  value with a limited number of dual simplex iterations */
   /* this routine fixes column x[j] at specified value bnd,
  solves resulting LP, and returns a lower bound to degradation
  of the objective, degrad >= 0 */
-  glp_prob *lp;
+  struct csa *csa = T->pcost;
+  glp_prob *lp = csa->work, *P = T->mip;
   glp_smcp parm;
-  int ret;
+  int i, jjj, ret;
   double degrad;
-  /* the current basis must be optimal */
-  xassert(glp_get_status(P) == GLP_OPT);
-  /* create a copy of P */
-  lp = glp_create_prob();
-  glp_copy_prob(lp, P, 0);
+  /* prepare lp */
+  if (lp == NULL)
+  {  /* the current basis must be optimal */
+ xassert(glp_get_status(P) == GLP_OPT);
+ /* create a copy of mip */
+ lp = glp_create_prob();
+ glp_copy_prob(lp, P, 0);
+ csa->work = lp;
+  }
+  else
+  {  /* restore original values */
+ for (i = 1; i <= P->m; i++)
+ {  lp->row[i]->stat = P->row[i]->stat;
+lp->row[i]->prim = P->row[i]->prim;
+lp->row[i]->dual = P->row[i]->dual;
+ }
+ for (jjj = 1; jjj <= P->n; jjj++)
+ {  lp->col[jjj]->stat = P->col[jjj]->stat;
+lp->col[jjj]->prim = P->col[jjj]->prim;
+lp->col[jjj]->dual = P->col[jjj]->dual;
+ }
+ lp->valid = 0;
+  }
   /* fix column x[j] at specified value */
   glp_set_col_bnds(lp, j, GLP_FX, bnd, bnd);
   /* try to solve resulting LP */
@@ -478,8 +500,9 @@ static double eval_degrad(glp_prob *P, int j, double bnd)
   {  /* the simplex solver failed */
  degrad = 0.0;
   }
-  /* delete the copy of P */
-  glp_delete_prob(lp);
+  /* restore column x[j] type and bounds */
+  glp_set_col_bnds(lp, j, P->col[j]->type, P->col[j]->lb,
+ P->col[j]->ub);
   return degrad;
 }
 
@@ -550,7 +573,7 @@ static double eval_psi(glp_tree *T, int j, int brnch)
  if (csa->dn_cnt[j] == 0)
  {  /* initialize down pseudocost */
 beta = T->mip->col[j]->prim;
-degrad = eval_degrad(T->mip, j, floor(beta));
+degrad = eval_degrad(T, j, floor(beta));
 if (degrad == DBL_MAX)
 {  psi = DBL_MAX;
goto done;
@@ -565,7 +588,7 @@ static double eval_psi(glp_tree *T, int j, int brnch)
  if (csa->up_cnt[j] == 0)
  {  /* initialize up pseudocost */
 beta = T->mip->col[j]->prim;
-degrad = eval_degrad(T->mip, j, ceil(beta));
+degrad = eval_degrad(T, j, ceil(beta));
 if (degrad == DBL_MAX)
 {  psi = DBL_MAX;
goto done;
@@ -604,9 +627,11 @@ int ios_pcost_branch(glp_tree *T, int *_next)
 #endif
   int j, jjj, sel;
   double beta, psi, d1, d2, d, dmax;
+  struct csa *csa;
   /* initialize the working arrays */
   if (T->pcost == NULL)
  T->pcost = ios_pcost_init(T);
+  csa = T->pcost;
   /* nothing has been chosen so far */
   jjj = 0, dmax = -1.0;
   /* go through the list of branching candidates */
@@ -658,6 +683,11 @@ int ios_pcost_branch(glp_tree *T, int *_next)
  jjj = branch_mostf(T, &sel);
   }
 done: *_next = sel;
+  if (csa->work != NULL)
+  {  /* clean up working problem for next round */
+ glp_delete_prob(csa->work);
+ csa->work = NULL;
+  }
   return jjj;
 }
 
diff --git a/src/bfd.c b/src/bfd.c
index dece376..89d547a 10

Re: [Help-glpk] Compiling GLPK with stdcall calling convention

2017-01-08 Thread Andrew Makhorin 
> > Could you, please, consider adding this CDECL symbol to GLPK 4.61.
> 
> Done. Please see
> http://sourceforge.net/projects/noumenon/files/tmp/
> (Note that this is *not* an official release.)
> 
> To avoid defining some macros (i.e. CDECL) on compiling glpk on a
> platform other than GNU/Linux and MS Windows I made the changes in the
> following way:
> 
> #ifndef __WOE__
> int foo(...
> #else
> int __cdecl foo(...
> #endif
> 
> It is always possible to define __cdecl as an empty token sequence, so
> there should be no problem I hope.
> 
> Please check the package with VC10. (I've got only VC9.)
> 

Oops. I forgot to add #include "config.h" to appropriate files, sorry;
will fix that. You need to add the compiler option /D__WOE__=1 to the
makefile to get changes working properly.


___
Help-glpk mailing list
Help-glpk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-glpk

Re: [Help-glpk] Compiling GLPK with stdcall calling convention

2017-01-08 Thread Andrew Makhorin 
Hi Heinrich,

Thank you for your efforts.

> for Windows 32 two different calling conventions are used: __cdecl and
> __stdcall.
> 
> To use GLPK in conjunction with 32bit LibreOffice (or OpenOffice) Basic
> it is necessary to compile the GLPK library with __stdcall.
> 
> Compilation with __stdcall can be achieved by using the /Gz compiler
> option for Visual Studio Express C++.
> 
> Unfortunately this is not enough. All functions passed to qsort must use
> the __cdecl calling convention.

I'd like just to know why MSVC developers didn't provide a stdcall
version of the C lib. 

> 
> On Github I have set up a repository with a patched GLPK 4.60 which
> allows both compiling with __cdecl and with __stdcall:
> https://github.com/xypron/glpk/tree/glpk-4.60-stdcall
> 
> The essential patch is
> https://github.com/xypron/glpk/commit/471b8ee233da57391b0f4401380c0405f7ab2455
> 
> It adds a symbol CDECL that is defined in config.h and applied to the
> relevant comparison functions.
> 
> I have also added a Makefile and build batch file but these are not
> essential.
> 
> Could you, please, consider adding this CDECL symbol to GLPK 4.61.

Done. Please see
http://sourceforge.net/projects/noumenon/files/tmp/
(Note that this is *not* an official release.)

To avoid defining some macros (i.e. CDECL) on compiling glpk on a
platform other than GNU/Linux and MS Windows I made the changes in the
following way:

#ifndef __WOE__
int foo(...
#else
int __cdecl foo(...
#endif

It is always possible to define __cdecl as an empty token sequence, so
there should be no problem I hope.

Please check the package with VC10. (I've got only VC9.)


Best regards,

Andrew Makhorin


___
Help-glpk mailing list
Help-glpk@gnu.org
https://lists.gnu.org/mailman/listinfo/help-glpk