RE: [Help-glpk] RE: GLPK on 64 bit Linux

[Hammond, Paul]

Thanks for the information Xypron. I knew Bjorns stuff wasn't maintained but 
wasn't aware of the alternative.

Paul

-----Original Message-----
From: glpk xypron [mailto:address@hidden 
Sent: 25 August 2010 21:49
To: Hammond, Paul (ISGT); address@hidden
Subject: 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: 'address@hidden'
> Cc: 'address@hidden'
> 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: 'address@hidden'
> Cc: 'address@hidden'
> 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
> 

-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

--------------------------------------------------------------------------
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 cannot access these 
links, please notify us by reply message and we will send the contents to you. 
By messaging with Morgan Stanley you consent to the foregoing.