Mark J. Roberts, <mjr at statesmean.com>, writes:
> import java.math.BigInteger;
>
> public class Test {
> public static void main(String[] args) {
> BigInteger x = new BigInteger("10000000000000000000");
> BigInteger y = new BigInteger("4294967296");
> System.out.println(x.divide(y));
> }
> }
>
> mjr::mjr$ javac Test.java ; java -cp . Test
> 2328306436
> mjr::mjr$ gcj --main=Test -o test Test.java ; ./test
> 1156841472
This incorrect value is approximately half the correct one, yes. But
here is a more important clue:
It is EXACTLY half the remainder x%y, which is 2313682944. The faulty
code is returning half the remainder, rather than the quotient.
The MPN.divide function [1] appears (judging by the code in the caller)
to return the quotient and remainder in the single array "xwords", with
the remainder in the "ylen" least significant words and the quotient in
the higher significance words. So it's not too unreasonable that the
code could pull the remainder out of this array when it was aiming at
the quotient.
Furthermore (and this is highly suggestive), before MPN.divide is called
x and y are left shifted so that y is left justified in a word. The net
result of this is that the remainder value at offset 1 in the "xwords"
array is HALF the remainder x%y, which is exactly what is returned as
the quotient.
Only one problem with this interpretation: studying the code reasonably
closely I can't see a problem with how it unpacks the array. It looks
like it's correctly pointing at the quotient.
Of course, we can always postulate a buggy java compiler and say that
although the code looks OK, what is actually running is something
different. Maybe so. If instead of accessing xwords[2] it somehow
grabbed xwords[1], that would explain the failure. But if it were this
buggy you'd think there would be a lot of other problems as well.
Hal
[1] http://24.131.185.22/BigInteger.java
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://www.uprizer.com/mailman/listinfo/devl
