> On 12/4/2013 1:34 PM, Brian Burkhalter wrote: >> Hello, >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8029514 >> Webrev: http://cr.openjdk.java.net/~bpb/8029514/webrev/ >> >> The problem causing this failure is that the method getLower() used by >> Karatsuba multiplication is expected to return an unsigned value but >> instead returns 'this' if the parameter 'n' is not greater than the >> int-length of the BigInteger on which it is invoked. For >> multiplications in which there is a negative factor this could result >> in an incorrect product being obtained. >> >> The BigIntegerTest is also updated to reflect the modified thresholds >> (should have been in the patch for 8022181 but was not …).
Hmmm... it looks like that patch is correct and necessary if getLower() is receiving negative numbers. I'm not quite sure what happened there. My vague recollection was that at one point the arguments to Karatsuba multiply were conditioned to always be positive in the multiply() dispatching function, but that's apparently not the case in the current code. Thanks for letting me know about this. I didn't see the earlier bug report or the report that the thresholds were being changed. It would seem to me that the new thresholds are quite a bit higher than is optimal for the architectures I tested on (Linux 64-bit and Windows 32 bit, and a bit of Raspberry Pi Arm); I intentionally set my thresholds to be quite high and conservative. Is there a particular architecture that requires the thresholds to be set that high? What performance effect do those higher thresholds have on the most common architectures? -- Alan Eliasen elia...@mindspring.com http://futureboy.us/