[Help-glpk] Re: GLPK and nonlinear programming
On Tue, 2011-03-01 at 16:31 +, Alan Zinober wrote: We currently use AMPL and MINOS to run nonlinear programming problems. But the free edition of AMPL does not handle large problems. Is it possible to use GLPK or any other free package with a nonlinear solver? Alan No, Glpk does not support non-linear models. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: GLPK Complilink Visual Studio C++ 2008
Attached is a VS2010 project which will compile glpk as a dll. Simply unzip it in the top of an unzipped glpk 4 45 source distribution. It will create a subdirectory called glpk. Double click on the .sln in this directory and VSC++2010 should start. Click build. The dll will appear in glpk\glpk\Release. Looking at the attahed log file I think another step is needed in your setup. You must identify some functions to be exported by your dll. There are 2 ways to do this: The nuclear option (my preferred) is to edit glpk.h. I have had to do this anyway, and the result is a dll some 300k smaller. I don't want all these procedures starting with _ so delete them. The only answer I have had as to the reason for their presence is that they are there for some other reason. GLPK compiles fine without them. The SWIG interface to R hates them. Similarly all the ones starting lpx are deprecated we shan't be needing those shall we, use the knife. Select the functions you do want and preceede them with __declspec(dllexport). It will do no harm to stick static in front as well. So entries will look something like static __declspec(dllexport) int glp_some procedure.. Or use the .def file supplied with glpk. You configure you dll project to use this Configuration Properties - Linker - Input - Module Definition File - point to w32\glpk_4_45.def. The first method is probably better not only because the result is smaller but when run time linking against the dll the os has to search a hash table converting the name to an address. The more unessasary names the less efficient this must be. You could also edit the .def file to include only what you want. You might want to copy Config_VC from w32 to .\include and rename it config.h, you will then need to set /DHAVECONFIG_H as an additional compiler option. - Original Message - From: Nigel Galloway To: Leandro Zanotto Cc: help-glpk@gnu.org Subject: [Help-glpk] Re: GLPK Complilink Visual Studio C++ 2008 Date: Tue, 18 Jan 2011 16:22:09 + There are three possibilities to compile GLPK using Visual Studio. GLPK is designed as a library of routines which can be used in another program to solve systems of linear inequalities. These programs written by you produce the .exe. The glpk examples directory contains a number of such programs. Of particular intrest maybe glpsol.c. This produces an executable which solves models written in mathprog (see gmpl.pdf in the documentation). There are two ways to compile this: 1) Start a project as an Application and compile all the GLPK source code and glpsol.c into the project. 2) Start an empty project as a LIB and compile all the GLPK source code. Then start a second project as an Application with just the glpsol.c source code and a reference to glpk.h from GLPK and glpk.lib produced above (you might want to make this project dependant on the LIB project). This will produce an executable, say glpsol.exe, which you can use as in the first possibility. The advantage is that you can use the library with other C++ programs from the examples directory (Start new projects as applicitions) and possibly your own code when required. The final possibility is to compile it as a DLL. This is required when you want to access the GLPK library from outside of VisaulC++. See example t1.cs for C# in the examples library or numerous examples in Java in Xyperon's java distribution. I think starting with option 2 is what you need. Looking at your log file I think you have produced an MFC DLL. This is a microsoft specific thing, so can not be used outside Visual Studio, for say Java. You could use it with VisualC#. It is small because it only contains the application entry point and cross references to a LIB file for the code. So you will also need the LIB file. You would only need this if you want to work within Visual Studio and be able to control the run time loading of GLPK library code. The DLL in option 3 can be built in Visual Studio as a Win32 application project by changing Configuration Properties - General - Configuration Type to Dynamic Library (.dll). before compiling it. - Original Message - From: Leandro Zanotto To: nigel_gallo...@operamail.com Subject: GLPK Complilink Visual Studio C++ 2008 Date: Mon, 17 Jan 2011 13:21:07 -0200 Hi Nigel, I am trying to compile the glpk here on VS C++ 2088, the sourceforge user Xpyron told me that you know it. Could you just explain what is going on here? I put the files on Source Files folder, I set it as a DLL project and I included the path of include folder whre we can find the glpk.h and others .h files. It was compiled. If I change the project configuration to lib it compiles too, but .exe not, ok I know I need an entry point (main class). My question is, after compiling on VS C++ 2008 the dll file has only 13kb and if I
[Help-glpk] Re: GLPK Complilink Visual Studio C++ 2008
There are three possibilities to compile GLPK using Visual Studio. GLPK is designed as a library of routines which can be used in another program to solve systems of linear inequalities. These programs written by you produce the .exe. The glpk examples directory contains a number of such programs. Of particular intrest maybe glpsol.c. This produces an executable which solves models written in mathprog (see gmpl.pdf in the documentation). There are two ways to compile this: 1) Start a project as an Application and compile all the GLPK source code and glpsol.c into the project. 2) Start an empty project as a LIB and compile all the GLPK source code. Then start a second project as an Application with just the glpsol.c source code and a reference to glpk.h from GLPK and glpk.lib produced above (you might want to make this project dependant on the LIB project). This will produce an executable, say glpsol.exe, which you can use as in the first possibility. The advantage is that you can use the library with other C++ programs from the examples directory (Start new projects as applicitions) and possibly your own code when required. The final possibility is to compile it as a DLL. This is required when you want to access the GLPK library from outside of VisaulC++. See example t1.cs for C# in the examples library or numerous examples in Java in Xyperon's java distribution. I think starting with option 2 is what you need. Looking at your log file I think you have produced an MFC DLL. This is a microsoft specific thing, so can not be used outside Visual Studio, for say Java. You could use it with VisualC#. It is small because it only contains the application entry point and cross references to a LIB file for the code. So you will also need the LIB file. You would only need this if you want to work within Visual Studio and be able to control the run time loading of GLPK library code. The DLL in option 3 can be built in Visual Studio as a Win32 application project by changing Configuration Properties - General - Configuration Type to Dynamic Library (.dll). before compiling it. - Original Message - From: Leandro Zanotto To: nigel_gallo...@operamail.com Subject: GLPK Complilink Visual Studio C++ 2008 Date: Mon, 17 Jan 2011 13:21:07 -0200 Hi Nigel, I am trying to compile the glpk here on VS C++ 2088, the sourceforge user Xpyron told me that you know it. Could you just explain what is going on here? I put the files on Source Files folder, I set it as a DLL project and I included the path of include folder whre we can find the glpk.h and others .h files. It was compiled. If I change the project configuration to lib it compiles too, but .exe not, ok I know I need an entry point (main class). My question is, after compiling on VS C++ 2008 the dll file has only 13kb and if I use the make file that comes with GLPK to build it the file size will be 803kb. Something is wrong here. Please check my log file. I will change the GLPK for university class. Thanks Build Log Build started: Project: glpk, Configuration: Release|Win32 Command Lines Creating temporary file d:\CUDAProjects\TestFiles\simplex\glpk\glpk\Release\RSP0262125268.rsp with contents [ /O2 /Oi /GL /I C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\w32 /I C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\amd /I C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src /I C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\include\\ /I C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\colamd /D DHAVE_CONFIG_H /D _CRT_SECURE_NO_WARNINGS /D _AFXDLL /D _MBCS /D _WINDLL /FD /EHsc /MD /Gy /FoRelease\\ /FdRelease\vc90.pdb /W3 /c /Zi /TC C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glptsp.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpssx02.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpssx01.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpsql.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpspx02.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpspx01.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpspm.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpsdf.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpscl.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpscf.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glprng02.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glprng01.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glprgr.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpqmd.c C:\Users\Leandro\Desktop\Trabalhos\Simplex Project\glpk-4.45\src\glpnpp05.c
[Help-glpk] Re: glpk for mac os x
On Thu, 2011-01-13 at 15:41 +, Patrick Winrow wrote: Good day, I need help to download glpk for my mac, how do i do it? Best regards, Patrick You can download the glpk distribution tarball and then build glpk in a standard way (i.e. configure/make). The GLPK distribution tarball can be found on http://ftp.gnu.org/gnu/glpk/ [via http] and ftp://ftp.gnu.org/gnu/glpk/ [via FTP]. It can also be found on one of our FTP mirrors; please use a mirror if possible. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK Help - compile GLPK inside Visual C++ 2008
Hello Leonardo, I have no experience on setting up GLPK as a proper Visual C project. May be somebody else on the list has. GLPK comes with Makefiles that can be used from the console. Unzip glpk-4.45.tar.gz. Open a console windows (cmd.exe). Depending on whether you are working on 32 or 64bit Windows, please, navigate to directory glpk-4.45\w32 or glpk-4.45\w64. Check the paths specified in Build_GLPK_with_VC9.bat. Execute Build_GLPK_with_VC9.bat. see http://en.wikibooks.org/wiki/GLPK/Windows A description on using GLPK in Visual C++ can be found in http://pitt.chapter.informs.org/files/Intro_To_GLPK_Slides.pdf Best regards Xypron Original-Nachricht Datum: Mon, 27 Dec 2010 19:44:41 + Betreff: GLPK Help Hi XYPRON, I am trying to compile GLPK inside Visual C++ 2008 but it is hard until now. I created a new empty project , placed the files (.c) and the headers, but I can't build it, there is a link problem. Iwould like to modify some files and build a new dll (lib) file. Do you know how to do it? Thank you. -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the Reply feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=1477882 -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: GLPK not shows a result
Hello Eduardo, I found the following paper to be insightful for finding better formulations: Norbert Ascheuer, Matteo Fischetti, Martin Grötschel Solving the Asymmetric Travelling Salesman Problem with Time Windows by Branch-and-Cut Appeared in: Math. Program., Ser. A, Vol 90, No 3: 475-506 (2000) http://opus4web.zib.de/documents-zib/423/SC-99-31.pdf Best regards Xypron Original-Nachricht Datum: Wed, 10 Nov 2010 16:59:25 +0300 Betreff: [Help-glpk] Re: GLPK not shows a result On Wed, 2010-11-10 at 12:59 +0100, Eduardo Sanjurjo wrote: Hello, I have this AMPL model, but when I execute with GLPK, I can't get any results. -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK memory leak?
Hello Adriana Regarding memory leakage. You mentioned earlier you create a lot of easy GLPK instances. Would that number in the thousands then? And do you delete these GLPK instances when you've finished with them? Or do you let them stack up in the street instead? If so, that would be a client-side issue! For those programming in C++. Enclose the GLPK instance in a dedicated class and then add 'glp_delete_prob' to the destructor. When instances of that class go out of scope, the resources used by GLPK will automatically release. You can use the same idiom for closing files too without having to remember to add dedicated code. This particular design pattern is described in one of Scott Meyers books, if I recall correctly. regards Robbie --- Robbie Morrison PhD student -- policy-oriented energy system simulation Technical University of Berlin (TU-Berlin), Germany University email (redirected) : morri...@iet.tu-berlin.de Webmail (preferred) : rob...@actrix.co.nz [from Webmail client] ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK memory leak?
I'm using the GLPKMEX interface to GLPK for Matlab, and I think I've isolated GLPK as the cause for my program to slowly use more and more memory, leading me to believe that there's a memory leak issue going on. I checked the code for GLPKMEX since it's only one file, and it appears that all memory that is allocated is also freed. However, GLPK has lots of functions, and I don't want to go through all of them and check for leaks. Are you aware of any memory leaks in GLPK? In my case, I'm running it on 64-bit Unix, and each individual problem that is solved is very small (takes 1 second or so) but I run lots and lots of problems of this kind, so a typical run is about 5-6 hours. Any tips you have on how to avoid or fix this issue would be appreciated. Thank you! I don't think this is glpk fault. You can check utilization of the memory used by glpk routines with the routine glp_mem_usage (for details please see the reference manual); it allows to see how much memory is currently allocated by glpk. If all glpk program objects have been deleted, only a small (about 200 bytes) memory block remains allocated; to free it you can use the routine glp_free_env, which guarantees deallocating all the memory used by glpk. It seems to me that you should search for the memory leak in glpkmex or in your application. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK memory leak?
To: Adriana Kovashka adri...@cs.utexas.edu Subject: [Help-glpk] Re: GLPK memory leak? Message-ID: 1288108851.2915.16.ca...@host From:Andrew Makhorin m...@gnu.org Date:Tue, 26 Oct 2010 20:00:51 +0400 I'm using the GLPKMEX interface to GLPK for Matlab, and I think I've isolated GLPK as the cause for my program to slowly use more and more memory, leading me to believe that there's a memory leak issue going on. I checked the code for GLPKMEX since it's only one file, and it appears that all memory that is allocated is also freed. However, GLPK has lots of functions, and I don't want to go through all of them and check for leaks. Are you aware of any memory leaks in GLPK? In my case, I'm running it on 64-bit Unix, and each individual problem that is solved is very small (takes 1 second or so) but I run lots and lots of problems of this kind, so a typical run is about 5-6 hours. Any tips you have on how to avoid or fix this issue would be appreciated. Thank you! I don't think this is glpk fault. You can check utilization of the memory used by glpk routines with the routine glp_mem_usage (for details please see the reference manual); it allows to see how much memory is currently allocated by glpk. If all glpk program objects have been deleted, only a small (about 200 bytes) memory block remains allocated; to free it you can use the routine glp_free_env, which guarantees deallocating all the memory used by glpk. It seems to me that you should search for the memory leak in glpkmex or in your application. Hello Adriana I concur with Andrew. I have never seen memory leak from GLPK since version 4.25 (19-Dec-2007) when I started working with the API. Both on 32-bit and 64-bit Linux. Every new build of my application is tested with 'valgrind' on a small run and occasionally I check a full sized simulation. Like you, I also make lots of little GLPK problems. Ideally, one should mop up with 'glp_free_env' on termination as Andrew suggests, but that's not your problem. It seems to me it would be hard to leak memory directly from Matlab by poor scripting. Have you tried running Matlab and your model from within a memory checker? Otherwise you contact The MathWorks. As an aside, I thoroughly recommend 'std::[tr1::]shared_ptr' smart pointers from Boost, when programming in C++. Robbie --- Robbie Morrison PhD student -- policy-oriented energy system simulation Technical University of Berlin (TU-Berlin), Germany University email (redirected) : morri...@iet.tu-berlin.de Webmail (preferred) : rob...@actrix.co.nz [from Webmail client] ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] RE: GLPK on 64 bit Linux
Hello Paul Just to let you know that much of the information Xypron gave you (in a parallel posting) is also available from the GLPK wikibook page: http://en.wikibooks.org/wiki/GLPK/Java In light of your email, I just added the following note: In particular, users have reported faulty floating point arithmetic when deployed on 64-bit Linux systems. One aim of the GLPK wikibook is to collect information about the various secondary projects clustered around GLPK. And especially their current status and limitations. with best wishes, Robbie To: help-glpk@gnu.org Subject: [Help-glpk] RE: GLPK on 64 bit Linux Message-ID: 7552712.20100825213...@gnu.org From: Hammond, Paul paul.hamm...@morganstanley.com Date:Wed, 25 Aug 2010 21:35:23 +0400 Hi, You may recall some time back that I had issues with numerical differences running GLPK-Java on 64 bit Linux that could not be explained by simply a different floating point precision. Some months ago, I believe I found an issue, and wanted to share it with everybody, sorry didn't post it sooner, just slipped my mind. [snip: remainder of post] --- Robbie Morrison PhD student -- policy-oriented energy system simulation Technical University of Berlin (TU-Berlin), Germany University email (redirected) : morri...@iet.tu-berlin.de Webmail (preferred) : rob...@actrix.co.nz [from Webmail client] ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] RE: GLPK on 64 bit Linux
Hi,
You may recall some time back that I had issues with
numerical differences running GLPK-Java on 64 bit Linux that could not be
explained by simply a different floating point precision. Some months ago, I
believe I found an issue, and wanted to share it with everybody, sorry didn
#8217;t
post it sooner, just slipped my mind.
If you look at the GKPK JNI #8216;C #8217; bridging file
in GLPK Java, called glpk_jni.c, you can see casting in the methods, for
example:
JNIEXPORT jdouble JNICALL
Java_org_gnu_glpk_GlpkSolver_getRowDual(JNIEnv *env,
jobject obj, jint i)
{
return
(jint)lpx_get_row_dual(get_lpx(env, obj), (int)i);
}
Notice that it returns a jdouble, but the casting is to a
jint.
If we look in the jni.h file, and in turn the jni_md.h
which it includes, we can see that jint is typedefed to a jsize and in turn to
an int. On a 64 bit platform, sometimes an int can remain at 32 bit.
If you look at all the methods, you will notice that
whether the methods return a jdouble, or a jint, they are *always* cast to a
jint, perhaps a cut and paste error. The casting to jint in 32 bit does not
seem to be an issue, not sure why as I thought that casting to an int would
lose the decimal part regardless but it seems to be passing through the bit
pattern unchanged, which is then returned and interpreted as a floating point
number. Even on a 32 bit platform, doubles are normally 64 bit in 2x32 bit
words, so one would think that would be still an issue in 32 bit but it seems
to work on 32 bit.
Here are some of the problematic JNI signatures,
interesting bits are bolded. When I changed the (jint) casts to (jdouble)
casts, recompiled and reran on 64 bit, I did not get the errors I got before,
it seemed to solve the problem.
JNIEXPORT jdouble JNICALL
Java_org_gnu_glpk_GlpkSolver_getRowDual(JNIEnv *env,
jobject obj, jint i)
{
return (jint)lpx_get_row_dual(get_lpx(env,
obj), (int)i);
}
JNIEXPORT jdouble JNICALL
Java_org_gnu_glpk_GlpkSolver_getColPrim(JNIEnv *env,
jobject obj, jint j)
{
return (jint)lpx_get_col_prim(get_lpx(env,
obj), (int)j);
}
JNIEXPORT jdouble JNICALL
Java_org_gnu_glpk_GlpkSolver_getColDual(JNIEnv *env,
jobject obj, jint j)
{
return (jint)lpx_get_col_dual(get_lpx(env,
obj), (int)j);
}
Paul
From: Hammond, Paul
(IDEAS)
Sent: 25 March 2010 11:24
To: 'help-glpk@gnu.org'
Cc: 'bug-g...@gnu.org'
Subject: RE: GLPK on 64 bit Linux
Correcting the bug-glpk address,
I had a stray dot at the end.
From: Hammond, Paul
(IDEAS)
Sent: 25 March 2010 11:01
To: 'help-glpk@gnu.org'
Cc: 'bug-g...@gnu.org.'
Subject: GLPK on 64 bit Linux
Hi,
I #8217;m including bug-glpk here as this
is potentially a bug, but it could be something we are doing wrong.
We are using GLPK with Java
(glpk-java-1.0.5), but to date have been using it in a 32 bit Linux environment
and it #8217;s been fine (apart from crashes which we put down to the fact
it #8217;s not thread safe)
Now we are trying to use it in a 64 bit
Linux environment and encountering some strange issues and I #8217;m just
wondering if anybody else has encountered these and how we might solve it.
To move to 64 bit, we recompiled the C code
on 64 bit to produce a new shared object linked to it. It runs and executes no
problem. For most of our inputs, it gives the same outputs as before, save for
some very small diffs which I put down to the different floating point
rounding.
However, there are cases where a few of the
numbers differ by amounts that cannot be put down to rounding. We have
sometimes a fraction like .8xxx going to 0, or we have large numbers differing
by 10-15%. Again, this is only in very few of the output variables out of quite
a lot (all the others match fine) and many sets of inputs have no problem but
it #8217;s enough to pose an issue if it goes wrong for even some of our
inputs.
We have dumped the inputs to a .dat file to
confirm the inputs are the same going in for both 32 bit and 64 bit. It #8217;s
the same Java software calling the solver so this should be the case.
Does anybody know about such issues with 64
bit and the cause? Is there some particular compile flags or switches we need
to use? Is there anywhere on the net a confirmed working binary version of GLPK
for Java on 64 bit?
If this is completely new and you would
like to investigate, what would you need to be supplied with as a test case to
look into the problem?
Thanks,
Paul
NOTICE: If you have received this communication in error, please destroy all
electronic and paper copies and notify the sender immediately. Mistransmission
is not intended to waive confidentiality or privilege. Morgan Stanley reserves
the right, to the extent permitted under applicable law, to monitor electronic
communications. This message is subject to terms available at the following
link: http://www.morganstanley.com/disclaimers. If you
Re: [Help-glpk] RE: GLPK on 64 bit Linux
Hello Paul,
the file glpk_jni.c does not exist in GLPK for Java 1.0.5 but in
GLPK 4.8 Java Interface downloadable from bjoern.dapnet.de.
The latter has not been maintained for several years.
Please, install GLPK 4.44 and SWIG 2.0.0 and download GLPK for Java
1.0.14 from
http://glpk-java.sourceforge.net
When building GLPK for Java 1.0.14 a mapping file
glpk-java-1.0.14/swig/src/c/glpk_wrap.c
is generated containing the following mapping:
SWIGEXPORT jdouble JNICALL Java_org_gnu_glpk_GLPKJNI_glp_1get_1row_1dual(JNIEnv
*jenv, jclass jcls, jlong jarg1, jobject jarg1_, jint jarg2) {
jdouble jresult = 0 ;
glp_prob *arg1 = (glp_prob *) 0 ;
int arg2 ;
double result;
(void)jenv;
(void)jcls;
(void)jarg1_;
arg1 = *(glp_prob **)jarg1;
arg2 = (int)jarg2;
{
jmp_buf glp_java_env;
glp_java_callback_env[glp_java_callback_level] = glp_java_env;
if (setjmp(glp_java_env)) {
glp_java_throw(jenv, function glp_get_row_dual failed);
} else {
glp_error_hook(glp_java_error_hook, glp_java_env);
result = (double)glp_get_row_dual(arg1,arg2);;
}
glp_java_callback_env[glp_java_callback_level] = NULL;
glp_error_hook(NULL, NULL);
}
jresult = (jdouble)result;
return jresult;
}
Best regards
Xypron
Original-Nachricht
Datum: Wed, 25 Aug 2010 21:35:23 +0400
Betreff: [Help-glpk] RE: GLPK on 64 bit Linux
Hi,
You may recall some time back that I had issues with
numerical differences running GLPK-Java on 64 bit Linux that could not be
explained by simply a different floating point precision. Some months ago,
I
believe I found an issue, and wanted to share it with everybody, sorry
didn #8217;t
post it sooner, just slipped my mind.
If you look at the GKPK JNI #8216;C #8217; bridging file
in GLPK Java, called glpk_jni.c, you can see casting in the methods, for
example:
JNIEXPORT jdouble JNICALL
Java_org_gnu_glpk_GlpkSolver_getRowDual(JNIEnv *env,
jobject obj, jint i)
{
return
(jint)lpx_get_row_dual(get_lpx(env, obj), (int)i);
}
Notice that it returns a jdouble, but the casting is to a
jint.
If we look in the jni.h file, and in turn the jni_md.h
which it includes, we can see that jint is typedefed to a jsize and in
turn to
an int. On a 64 bit platform, sometimes an int can remain at 32 bit.
If you look at all the methods, you will notice that
whether the methods return a jdouble, or a jint, they are *always* cast to
a
jint, perhaps a cut and paste error. The casting to jint in 32 bit does
not
seem to be an issue, not sure why as I thought that casting to an int
would
lose the decimal part regardless but it seems to be passing through the
bit
pattern unchanged, which is then returned and interpreted as a floating
point
number. Even on a 32 bit platform, doubles are normally 64 bit in 2x32 bit
words, so one would think that would be still an issue in 32 bit but it
seems
to work on 32 bit.
Here are some of the problematic JNI signatures,
interesting bits are bolded. When I changed the (jint) casts to (jdouble)
casts, recompiled and reran on 64 bit, I did not get the errors I got
before,
it seemed to solve the problem.
JNIEXPORT jdouble JNICALL
Java_org_gnu_glpk_GlpkSolver_getRowDual(JNIEnv *env,
jobject obj, jint i)
{
return (jint)lpx_get_row_dual(get_lpx(env,
obj), (int)i);
}
JNIEXPORT jdouble JNICALL
Java_org_gnu_glpk_GlpkSolver_getColPrim(JNIEnv *env,
jobject obj, jint j)
{
return (jint)lpx_get_col_prim(get_lpx(env,
obj), (int)j);
}
JNIEXPORT jdouble JNICALL
Java_org_gnu_glpk_GlpkSolver_getColDual(JNIEnv *env,
jobject obj, jint j)
{
return (jint)lpx_get_col_dual(get_lpx(env,
obj), (int)j);
}
Paul
From: Hammond, Paul
(IDEAS)
Sent: 25 March 2010 11:24
To: 'help-glpk@gnu.org'
Cc: 'bug-g...@gnu.org'
Subject: RE: GLPK on 64 bit Linux
Correcting the bug-glpk address,
I had a stray dot at the end.
From: Hammond, Paul
(IDEAS)
Sent: 25 March 2010 11:01
To: 'help-glpk@gnu.org'
Cc: 'bug-g...@gnu.org.'
Subject: GLPK on 64 bit Linux
Hi,
I #8217;m including bug-glpk here as this
is potentially a bug, but it could be something we are doing wrong.
We are using GLPK with Java
(glpk-java-1.0.5), but to date have been using it in a 32 bit Linux
environment
and it #8217;s been fine (apart from crashes which we put down to the fact
it #8217;s not thread safe)
Now we are trying to use it in a 64 bit
Linux environment and encountering some strange issues and I #8217;m just
wondering if anybody else has encountered these and how we might solve it.
To move to 64 bit, we recompiled the C code
on 64 bit to produce a new shared object linked to it. It runs and
executes no
problem. For most of our inputs, it gives the same outputs as before, save
for
some
[Help-glpk] Re: GLPK Lab 4.44.1 release information
Hi Xypron, GLPK Lab has been updated to use GLPK 4.44. Thank you for making the distribution. Just tried it under Wine. All works fine. Andrew Makhorin ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: GLPK Lab 4.44.1 release information
Andrew and Xypron, It works as well in Windows XP Home - Atom CPU 1.3Mhz netbook. Noli On 6/4/10, Andrew Makhorin m...@gnu.org wrote: Hi Xypron, GLPK Lab has been updated to use GLPK 4.44. Thank you for making the distribution. Just tried it under Wine. All works fine. Andrew Makhorin ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK on 64 bit Linux
I #8217;m including bug-glpk here as this is potentially a bug, but it could be something we are doing wrong. We are using GLPK with Java (glpk-java-1.0.5), but to date have been using it in a 32 bit Linux environment and it #8217;s been fine (apart from crashes which we put down to the fact it #8217;s not thread safe) Now we are trying to use it in a 64 bit Linux environment and encountering some strange issues and I #8217;m just wondering if anybody else has encountered these and how we might solve it. To move to 64 bit, we recompiled the C code on 64 bit to produce a new shared object linked to it. It runs and executes no problem. For most of our inputs, it gives the same outputs as before, save for some very small diffs which I put down to the different floating point rounding. However, there are cases where a few of the numbers differ by amounts that cannot be put down to rounding. We have sometimes a fraction like .8xxx going to 0, or we have large numbers differing by 10-15%. Again, this is only in very few of the output variables out of quite a lot (all the others match fine) and many sets of inputs have no problem but it #8217;s enough to pose an issue if it goes wrong for even some of our inputs. We have dumped the inputs to a .dat file to confirm the inputs are the same going in for both 32 bit and 64 bit. It #8217;s the same Java software calling the solver so this should be the case. Does anybody know about such issues with 64 bit and the cause? Is there some particular compile flags or switches we need to use? Is there anywhere on the net a confirmed working binary version of GLPK for Java on 64 bit? If this is completely new and you would like to investigate, what would you need to be supplied with as a test case to look into the problem? Thank you for your report. Are the optimal objective values found by the 32- and 64-bit version of the solver identical or close to each other? If so, this is not a bug. If your lp/mip instance has multiple optima, it may happen that the 32-bit glpk solver finds one optimal solution while its 64-bit version finds another solution, which is optimal too. This is normal. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK on 64 bit Linux
Yes you're right, a given input resource may be allocated differently and is the case. But one thing that should remain constant though is the totals, what I'm talking about is that the totals of the allocations at the end of a given input do not equal that input. By way of illustration, take the often quoted example where the farmer is allocating his land to grow wheat or barley subject to constraints. In the output results, even if there are multiple optima, all the land should be allocated to either wheat or barley, but I find cases where the total land in the output is less or greater than the amount coming in, and it's too great to be a rounding error. It may happen that it is not profitable to allocate all the land until you require all the land to be allocated by introducing an appropriate equiality constraint. Now my resource allocation problem is clearly different than the simple example above, I have many different resources to be allocated subject to more constraints, but the problem I have is essentially the same as this analogy. You can write the solution in a text file with glp_print_sol and see if the optimality conditions are satisfied. If they are, probably you missed some essential constraints. If not, please write your instance in mps or better in glpk lp/mip format and post it to me. Thanks. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] RE: GLPK on 64 bit Linux
Hi Andrew, Thanks for replying. Yes you're right, a given input resource may be allocated differently and is the case. But one thing that should remain constant though is the totals, what I'm talking about is that the totals of the allocations at the end of a given input do not equal that input. By way of illustration, take the often quoted example where the farmer is allocating his land to grow wheat or barley subject to constraints. In the output results, even if there are multiple optima, all the land should be allocated to either wheat or barley, but I find cases where the total land in the output is less or greater than the amount coming in, and it's too great to be a rounding error. Now my resource allocation problem is clearly different than the simple example above, I have many different resources to be allocated subject to more constraints, but the problem I have is essentially the same as this analogy. Paul -Original Message- From: Andrew Makhorin [mailto:m...@gnu.org] Sent: 25 March 2010 13:56 To: Hammond, Paul (IDEAS) Cc: help-glpk@gnu.org; bug-g...@gnu.org Subject: Re: GLPK on 64 bit Linux I #8217;m including bug-glpk here as this is potentially a bug, but it could be something we are doing wrong. We are using GLPK with Java (glpk-java-1.0.5), but to date have been using it in a 32 bit Linux environment and it #8217;s been fine (apart from crashes which we put down to the fact it #8217;s not thread safe) Now we are trying to use it in a 64 bit Linux environment and encountering some strange issues and I #8217;m just wondering if anybody else has encountered these and how we might solve it. To move to 64 bit, we recompiled the C code on 64 bit to produce a new shared object linked to it. It runs and executes no problem. For most of our inputs, it gives the same outputs as before, save for some very small diffs which I put down to the different floating point rounding. However, there are cases where a few of the numbers differ by amounts that cannot be put down to rounding. We have sometimes a fraction like .8xxx going to 0, or we have large numbers differing by 10-15%. Again, this is only in very few of the output variables out of quite a lot (all the others match fine) and many sets of inputs have no problem but it #8217;s enough to pose an issue if it goes wrong for even some of our inputs. We have dumped the inputs to a .dat file to confirm the inputs are the same going in for both 32 bit and 64 bit. It #8217;s the same Java software calling the solver so this should be the case. Does anybody know about such issues with 64 bit and the cause? Is there some particular compile flags or switches we need to use? Is there anywhere on the net a confirmed working binary version of GLPK for Java on 64 bit? If this is completely new and you would like to investigate, what would you need to be supplied with as a test case to look into the problem? Thank you for your report. Are the optimal objective values found by the 32- and 64-bit version of the solver identical or close to each other? If so, this is not a bug. If your lp/mip instance has multiple optima, it may happen that the 32-bit glpk solver finds one optimal solution while its 64-bit version finds another solution, which is optimal too. This is normal. -- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] RE: GLPK on 64 bit Linux
Andrew, I did not write the original code here I'm debugging, but it's certainly intended that there is a constraint that all the input must be allocated. I can double check that this is the case. In terms of presenting a test case, I'm quite new to GLPK, I'd have to read up n the formats you have below. We do make some calls when we're debugging to the following: solver.writeCpxlp(file + .dat); . solver.printSol(file + .sol); Would any of these files be sufficient? If not is there a call I can make on the solver from Java to give you the problem in the format you would need? Paul -Original Message- From: Andrew Makhorin [mailto:m...@gnu.org] Sent: 25 March 2010 14:37 To: Hammond, Paul (IDEAS) Cc: help-glpk@gnu.org Subject: Re: GLPK on 64 bit Linux Yes you're right, a given input resource may be allocated differently and is the case. But one thing that should remain constant though is the totals, what I'm talking about is that the totals of the allocations at the end of a given input do not equal that input. By way of illustration, take the often quoted example where the farmer is allocating his land to grow wheat or barley subject to constraints. In the output results, even if there are multiple optima, all the land should be allocated to either wheat or barley, but I find cases where the total land in the output is less or greater than the amount coming in, and it's too great to be a rounding error. It may happen that it is not profitable to allocate all the land until you require all the land to be allocated by introducing an appropriate equiality constraint. Now my resource allocation problem is clearly different than the simple example above, I have many different resources to be allocated subject to more constraints, but the problem I have is essentially the same as this analogy. You can write the solution in a text file with glp_print_sol and see if the optimality conditions are satisfied. If they are, probably you missed some essential constraints. If not, please write your instance in mps or better in glpk lp/mip format and post it to me. Thanks. -- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] RE: GLPK on 64 bit Linux
I did not write the original code here I'm debugging, but it's certainly intended that there is a constraint that all the input must be allocated. I can double check that this is the case. In terms of presenting a test case, I'm quite new to GLPK, I'd have to read up n the formats you have below. We do make some calls when we're debugging to the following: solver.writeCpxlp(file + .dat); . solver.printSol(file + .sol); Would any of these files be sufficient? If not is there a call I can make on the solver from Java to give you the problem in the format you would need? Yes, these files are sufficient. If possible, please use: solver.writeProb(file + .glp); rather than writeCpxlp. Thanks. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: Re: [Help-glpk] Re: GLPK MingW build files and PyGLPK
That sounds like a solution. Note though that whether compiling using your own MingW makefiles or make files compatible with MSYS (and hence Linux) you are using the same MingW compiler (gcc 3.4 as standard or gcc 4.2 if youv'e gone experimental). The difference must therefore be due to an option you are passing to the compiler, and not the particular make tool. Cygwin is far too complicated and your code will have dependencies. Any timings may depend on how you've built Cygwin. Good Luck, Nigel - Original Message - From: Luiz M. M. Bettoni To: Nigel Galloway , help-glpk , Andrew Makhorin Subject: Re: Re: [Help-glpk] Re: GLPK MingW build files and PyGLPK Date: Thu, 26 Nov 2009 08:47:00 -0300 Hi, Nigel, Andrew. I've build glpsol.exe with MSYS and cygwin. Besides it's useful, the binary file has more than double sized and the solver looks like quite slower. So, for my testing purposes, I'll use my own MingW build files. In Gusek package I'll use Xypron pre-built files. Thanks, guys! Luiz At 16:59, Nigel Galloway wrote: You should probably add the MSYS extensions to MingW, these include a make utility compatible with Linux. This is what I usually use to compile glpk on windows using NetBeans rather than Visual C++ as the IDE. I make no changes. Good Luck, Nigel - Original Message - From: Andrew Makhorin m...@gnu.org To: Luiz Bettoni bett...@cpgei.ct.utfpr.edu.br Cc: help-glpk help-glpk@gnu.org Subject: [Help-glpk] Re: GLPK MingW build files and PyGLPK Date: Thu, 5 Nov 2009 20:40:50 +0300 You do not intend to include MingW w32 build files in GLPK package anymore? On every GLPK launch i've patched them and sent to the list, but if no-one uses mingw to build GLPK (I'm alone? U), it's wast effort. If MingW build files isn't util anymore, I'm planning replace Gusek glpsol binaries by winglpk pre-build ones. If you build only the glpsol executable, why not to use Cygwin? It allows configuring and building the package in the standard way. Is there anything specific in Gusek that requires Mingw? -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: GLPK MingW build files and PyGLPK
Under cygwin gcc is run with default options '-g' (that includes debugging info into the executable) and '-O2'. On my 32-bit windows machine I build glpk using 'make CFLAGS=-O3', and the code is about 30% faster than the one built with MSVS 2010 'cl -O3'. I've experienced some issues using O3 cflag in past, but using O2 all looks great. 30% faster? Good. How you timed this? Testing some models using both builds (and some others, like MingW), I've seen that there is no build that runs all models in better time. Maybe in specific operations (like DB access or problem generation) it can be timed, but not in solve process (the longest task when reduce time become a problem). Sorry, I was wrong. Probably my opinion was based on some inaccurate experiments. It is surprising to me, but the code produced with 'gcc -O2' looks to be faster than with 'gcc -O3', though -O3 is claimed as the third and highest level enables even more optimizations by putting emphasis on speed over size, that includes optimizations enabled at -O2 and rename-register. (However, highly optimized code may overload the instruction cache and thus slow down the CPU performance.) Below here are solution times for dfl001.mps from netlib (solved with the lp presolver disabled): Cygwin GCC -O2: Time used: 183.3 secs Memory used: 8.1 Mb (8466625 bytes) Cygwin GCC -O3: Time used: 204.7 secs Memory used: 8.1 Mb (8466625 bytes) MSVC 10.0 -O2: Time used: 197.5 secs Memory used: 8.1 Mb (8466625 bytes) A note about GUSEK: building with cygwin the binary needs cygwin dll, a little big add to the package. And, if I presume that cygwin dll is as a system prerequisite, GUSEK will not be self-portable. I agree with you. Since Gusek is a Windows application, using a native executable not requiring dll is more convenient for the end-user. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: GLPK MingW build files and PyGLPK
I've build glpsol.exe with MSYS and cygwin. Besides it's useful, the binary file has more than double sized and the solver looks like quite slower. Under cygwin gcc is run with default options '-g' (that includes debugging info into the executable) and '-O2'. On my 32-bit windows machine I build glpk using 'make CFLAGS=-O3', and the code is about 30% faster than the one built with MSVS 2010 'cl -O3'. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: Re: [Help-glpk] Re: GLPK MingW build files and PyGLPK
Thanks, Nigel! I'll give it a try, can be an interesting alternative. By the way, as I've said, now I think that will be a good choice if Gusek adopt the winglpk binaries. Thanks for share! Luiz Nigel Galloway wrote: You should probably add the MSYS extensions to MingW, these include a make utility compatible with Linux. This is what I usually use to compile glpk on windows using NetBeans rather than Visual C++ as the IDE. I make no changes. Good Luck, Nigel ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK vs. SCIP for solving MIP Click to flag this post
I've grown used to GMPL, I haven't used it myself, but the modelling language Zimpl, which can be used with SCIP, appears to have similarities with MathProg. http://zimpl.zib.de/ _ Access your other email accounts and manage all your email from one place. http://clk.atdmt.com/UKM/go/167688463/direct/01/___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: GLPK vs. SCIP for solving MIP Click to flag this post
Yes, I've checked it out. It's similar in concept , but has some differences -I do not believe you get database connectivity with Zimpl - Zimpl allowes you to model if-then-else relationships between variable, dealing with the conditional variables under the hood, whereas GLPK forces you to make everything explicit. The path Mathprog-GLPK-LP-SCIP works fine. Cheers Kretch On Sat, Oct 3, 2009 at 12:54 AM, Tawny Owl tow_fo...@hotmail.com wrote: I've grown used to GMPL, I haven't used it myself, but the modelling language Zimpl, which can be used with SCIP, appears to have similarities with MathProg. http://zimpl.zib.de/ Use Hotmail to send and receive mail from your different email accounts. Find out how. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK installation problem on Linux with Matlab (recompile with -fPIC)
Hello Yimeng, This is a weird issue when glpkmex tries to call glpk on 64bit machines. I have it working on my machine. You'll need to recompile glpk with: make clean make CFLAGS+=-fPIC make check make install note: if you are using the 'with-gmp' configuration argument, you'll need to recompile gmp the same way as well. Good Luck, Niels ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: RE: [Help-glpk] Re: glpk 4.34 release information
Hello Mark, May I recommend to Andrew or Xypron that at least -O2 is set on for the VS2008 makefile? thank you for your recommendations Flag /O2 is described here http://msdn.microsoft.com/en-us/library/8f8h5cxt.aspx as a default setting for release builds. Flag /GL is described here http://msdn.microsoft.com/en-us/library/0zza0de8.aspx Some caveats do exist: The format of files produced with /GL in the current version may not be readable by subsequent versions of Visual C++. I will test with these two flags. Best regards Xypron -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: glpk 4.34 release information
Flag /O2 is described here http://msdn.microsoft.com/en-us/library/8f8h5cxt.aspx as a default setting for release builds. To generate a fastest code msdn recommends to use /Ox option (it includes /O2). ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
RE: [Help-glpk] Re: glpk 4.34 release information
Hi, Marc. This topic make me test some models with distinct builds of GLPK: http://lists.gnu.org/archive/html/help-glpk/2008-11/msg00026.html In 2 good machines (AMD Athlon64 2.200MHz, 2Gb DDR-400 / Intel Core 2 Duo 2x 2133 MHz, 2Gb DDR2-667), just replacing the glpsol.exe (all parameters still the same, i'm using all cuts), VS2008 build (from http://winglpk.sourceforge.net) cannot beat MinGW in all my tests. Off course, simple models are solved instantaneously, but on some of my huge problems i can see times like 80s vs 270s, for example. Maybe we can make a lot of tests and summarize it (using different machines, some different models from MIPLIB 2003) to be a pointer to users make a choice. Just a pointer, not the answer to all problems. Look, maybe a transportation problem in amd processor run faster with VS2008 build, but a plan scheduling in a intel run better with MinGW build (or not?). Best Regards, Luiz Em 6/12/2008 04:11, Meketon, Marc escreveu: Luis, I am curious that your MinGW execution times are so much faster than the VS2008 times. Would you know if the various optimization parameters are turned on for VS2008? -Marc I didn't use the VS2008 build 'cause it is much slower then MinGW build. On all my tests with several models in GMPL, the MinGW version take less than a half of VS2008 version time... ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
RE: [Help-glpk] Re: glpk 4.34 release information
Luiz, I'm not an expert on the compilation flags, so please double check what I'm trying to say in the following. The CFLAGS set for VS2008 is: /I. /DHAVE_CONFIG_H /nologo /W3 I do not know what the corresponding settings are for MinGW. It does not appear that any flag for optimization (such as /O2, /GL, etc.) is turned on for VS2008. I think that a comparison should be made between the two compilers when both have their optimization for speed settings adjusted to be as fast as possible. -Marc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luiz M. M. Bettoni Sent: Saturday, December 06, 2008 8:37 AM To: help-glpk@gnu.org Subject: RE: [Help-glpk] Re: glpk 4.34 release information Hi, Marc. This topic make me test some models with distinct builds of GLPK: http://lists.gnu.org/archive/html/help-glpk/2008-11/msg00026.html In 2 good machines (AMD Athlon64 2.200MHz, 2Gb DDR-400 / Intel Core 2 Duo 2x 2133 MHz, 2Gb DDR2-667), just replacing the glpsol.exe (all parameters still the same, i'm using all cuts), VS2008 build (from http://winglpk.sourceforge.net) cannot beat MinGW in all my tests. Off course, simple models are solved instantaneously, but on some of my huge problems i can see times like 80s vs 270s, for example. Maybe we can make a lot of tests and summarize it (using different machines, some different models from MIPLIB 2003) to be a pointer to users make a choice. Just a pointer, not the answer to all problems. Look, maybe a transportation problem in amd processor run faster with VS2008 build, but a plan scheduling in a intel run better with MinGW build (or not?). Best Regards, Luiz Em 6/12/2008 04:11, Meketon, Marc escreveu: Luis, I am curious that your MinGW execution times are so much faster than the VS2008 times. Would you know if the various optimization parameters are turned on for VS2008? -Marc I didn't use the VS2008 build 'cause it is much slower then MinGW build. On all my tests with several models in GMPL, the MinGW version take less than a half of VS2008 version time... ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: glpk 4.34 release information
Hi, Marc. I'm not an expert on the compilation flags, so please double check what I'm trying to say in the following. The CFLAGS set for VS2008 is: /I. /DHAVE_CONFIG_H /nologo /W3 I do not know what the corresponding settings are for MinGW. I'm not an expert on various fields, so sorry by misunderstood you previous message =) For MinGW i've just used the default DEV-C++ flags: -I. -DHAVE_CONFIG_H -O2 It does not appear that any flag for optimization (such as /O2, /GL, etc.) is turned on for VS2008. I think that a comparison should be made between the two compilers when both have their optimization for speed settings adjusted to be as fast as possible. I've just used default options. Maybe the GCC and VS2008 experts can do the tests with the best optimization flags =) Thanks! Luiz ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
RE: [Help-glpk] Re: glpk 4.34 release information
Thank Luiz. It does appear, based on the flags you said are set for MinGW, that MinGW does have full optimization turned on, while VS2008 does not. That is probably the reason why MinGW is faster. May I recommend to Andrew or Xypron that at least -O2 is set on for the VS2008 makefile? -Marc -Original Message- From: Luiz M. M. Bettoni [mailto:[EMAIL PROTECTED] Sent: Saturday, December 06, 2008 10:55 AM To: Meketon, Marc Cc: help-glpk@gnu.org Subject: Re: [Help-glpk] Re: glpk 4.34 release information Hi, Marc. I'm not an expert on the compilation flags, so please double check what I'm trying to say in the following. The CFLAGS set for VS2008 is: /I. /DHAVE_CONFIG_H /nologo /W3 I do not know what the corresponding settings are for MinGW. I'm not an expert on various fields, so sorry by misunderstood you previous message =) For MinGW i've just used the default DEV-C++ flags: -I. -DHAVE_CONFIG_H -O2 It does not appear that any flag for optimization (such as /O2, /GL, etc.) is turned on for VS2008. I think that a comparison should be made between the two compilers when both have their optimization for speed settings adjusted to be as fast as possible. I've just used default options. Maybe the GCC and VS2008 experts can do the tests with the best optimization flags =) Thanks! Luiz This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: glpk 4.34 release information
Hello Luiz, every GLPK release), but add a way to build GLPK directly from MinGW can be very useful for newbies. the only Windows build files for GLPK 4.34 that support ODBC connectivity are those for Visual Studio Express 2008 and the Windows SDK. Both can be downloaded free of charge from Microsoft. This is why I currently consider this build environment a good starting point. Executables and dlls for GLPK 4.34 can be downloaded from http://winglpk.sourceforge.net Have you created MinGW build files with ODBC support? This would be helpful. Third, i'm working with GMPL models calling glpsol.exe under a custom IDE build from SciTE for Windows. Someone has interest? I can public the source or pre-build versions if so. The interface is in English, but i need some help to translate the quick-start doc from Brazilian Portuguese. I would be very keen to be able to use an IDE with GLPK. It would be very kind if you could provide the source. Andrew, some restriction or recommendation to distribute it with a pre-build glpk bin? Please, have a look at the GNU Public Licence. The Scintalla/SciTE licence seems to be compatible with GPL, if you want to combine GLPK and some of the SciTE code into one package. Best regards Xypron begin:vcard fn:Xypron n:GLPK;Xypron adr:;;Germany email;internet:[EMAIL PROTECTED] tel;fax:+49 1803 663388 0451 x-mozilla-html:TRUE url:http://winglpk.sourceforge.net version:2.1 end:vcard ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK and Java using SWIG
NigelzGLPK.swg is the file in the pdf document in the section The SWIG Interface File. I've attached a copy. Also I've attached a bug report I made to make it work. You will probably need to make the same change. Good Luck Nigel Galloway - Original Message - From: Pierpaolo Caricato [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: GLPK and Java using SWIG Date: Thu, 31 May 2007 18:37:47 +0200 Dear Nigel, I'm a Ph.D in Operations Research at the University of Lecce, in Italy. I've just started working on how to get GLPK functions in Java (and in C# also). After some emails with Gabor Retvari I decided to use SWIG for this purpose. You preceded me! The pdf file you've just linked on the GLPK mailing list is very interesting. Where can I find the NigelzGLPK.swg file you use in the document? Could you please send it to me? Thank you very much! Best regards, Pierpaolo Caricato -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze NigelzGLPK.swg Description: Binary data bugReport.rtf Description: RTF file ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK is unable to read some .mps files
I've found that GLPK is unable to read some .mps files that can be read by other software. see http://www.sce.carleton.ca/faculty/chinneck/MPSreader/MPSobject.html I've attached 2 of these files since they seem to cause different errors when GLPK reads them. The error for 22433.mps looks like this: lpx_read_mps: reading problem data from `g:\PhdIdeas\mps\22433.mps'... lpx_read_mps: problem name not specified g:\PhdIdeas\mps\22433.mps:204: row ZOBJ not found The error for newdano.mps looks like this: lpx_read_mps: reading problem data from `g:\PhdIdeas\mps\newdano.mps'... lpx_read_mps: problem from_lp_ g:\PhdIdeas\mps\newdano.mps:581: missing coefficient value in field 4 What can I do to fix this problem? Use lpx_read_freemps (which reads mps files in free mps format) rather than lpx_read_mps. There are some violations of the standard (fixed) mps format in your mps files, so lpx_read_mps cannot read them. ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: GLPK matlab
Hello all, I am trying to install GLPK on Linux. I unzip and untar everything into the glpk-4.9 folder. Within this folder, I call the ./configure command which works fine. I do not have admin access on this machine, so I just want to install in my local directory. I do this by running make prefix=/home/myaccount/glpk-4.9 install At this point I get an error, saying all include/*.h files already exist, and the bin and lib folders are Not created and the libglpk.a file is Not created. I then try running this install in the directory Above glpk-4.9/ and bin and lib and libglpk.a are created in this parent directory, but this doesn't seem right, having to separate the install folders from glpk-4.9/ . Furthermore, mex doesn't seem to recognize the required files. After talking to Nicolo I'm pretty sure I have the GLPKmex package set up right. In which directory exactly should I be running make prefix= install? I dont have access to /usr/local/bin etc. Any assistance would be greatly appreciated. Best, Girish ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
Re: [Help-glpk] Re: GLPK matlab
On Wed, 2006-12-13 at 09:11 -0500, Girish Rao wrote: Hello all, I am trying to install GLPK on Linux. I unzip and untar everything into the glpk-4.9 folder. Within this folder, I call the ./configure command which works fine. I do not have admin access on this machine, so I just want to install in my local directory. I do this by running make prefix=/home/myaccount/glpk-4.9 install At this point I get an error, saying all include/*.h files already exist, and the bin and lib folders are Not created and the libglpk.a file is Not created. I then try running this install in the directory Above glpk-4.9/ and bin and lib and libglpk.a are created in this parent directory, but this doesn't seem right, having to separate the install folders from glpk-4.9/ . Furthermore, mex doesn't seem to recognize the required files. After talking to Nicolo I'm pretty sure I have the GLPKmex package set up right. In which directory exactly should I be running make prefix= install? I dont have access to /usr/local/bin etc. Any assistance would be greatly appreciated. Best, Girish Hi, Try specifying prefix at the configure phase. $ ./configure --prefix=/home/myaccount/glpk-4.9 $ make $ make install By the way latest version is 4.13 in case you did not notice. Baris ___ Help-glpk mailing list Help-glpk@gnu.org http://lists.gnu.org/mailman/listinfo/help-glpk
[Help-glpk] Re: glpk
I do not belong to the OR community. Anyway I need Linear Programming to
solve a problem. I start using glpk with diffilculty. At least I would
have expected that just adding a display statement in one of the simple
example file provided with glpk would entail no problem.
I just ran glpsol --model bpp.mod with some display statement added (see
below (111)) and obtained (222). I don't understand this behaviour since
the glpk lang.ps documentation explicitly shows that such statements as
display{i in I, j in J}: i,j,x[i,j]; are allowed.
If you wish to see results of optimization, you should specify the solve
statement preceding the display statement, that is:
...
minimize obj: sum{j in J} used[j];
/* objective is to minimize the number of bins used */
solve;
/* C.S. 15/12/05 */
display '*';
/* display{j in J}: j, used[j]; */
display '*';
/* display{i in I}: i; */
/* display{j in J}: j; */
display{ii in I, jj in J}: ii,jj,x[ii,jj];
...
___
Help-glpk mailing list
Help-glpk@gnu.org
http://lists.gnu.org/mailman/listinfo/help-glpk
