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

[Hammond, Paul]

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

 

 









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.

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.

 

If you look at the GKPK JNI ‘C’ 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’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’s been fine (apart from crashes which we put down to the fact it’s not thread safe)

 

Now we are trying to use it in a 64 bit Linux environment and encountering some strange issues and I’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’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’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 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.