JDK 9 RFR of 8026236: Add PrimeTest for BigInteger [TEST-ONLY]

Brian Burkhalter brian.burkhalter at oracle.com
Fri Apr 25 00:12:53 UTC 2014


I have posted an updated patch here:


Thanks for your comments.


On Apr 23, 2014, at 7:28 AM, Peter Levart <peter.levart at gmail.com> wrote:

> Hi Brian,
> There seems to be a confusion between "upperBound" and the 1st "n" primer numbers. You pass "upperBound" as the parameter "n" of the parsePrimes() method which returns 1st "n" primes from the file (it can return less primes if the file is smaller).
> I suggest doing the following:
> - make parsePrimes() take "n" as it does and return 1st "n" primes from the file, but collect them into a NavigableSet (TreeSet) like that:
>     private static NavigableSet<BigInteger> parsePrimes(File f, long n) throws IOException {
>         GZIPInputStream gis = new GZIPInputStream(new FileInputStream(f));
>         BufferedReader br = new BufferedReader(new InputStreamReader(gis));
>         try (Stream<String> lines = br.lines()) {
>             return lines.limit(n).map(BigInteger::new).collect(toCollection(TreeSet::new));
>         }
>     }
> This would serve two purposes:
> - you could obtain the largest prime number from the set easily (NavigableSet.last()) and use it as the "upperBound" for the range of integers you test.
> - your test for containment would be faster - O(log2(n)) instead of O(n)
> Regards, Peter
> On 04/23/2014 01:48 AM, Brian Burkhalter wrote:
>> Hello,
>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8026236
>> Patch:	http://cr.openjdk.java.net/~bpb/8026236/webrev.00/
>> This test provides a rudimentary verification of isProbablePrime() by:
>> 1 - checking that the first 100000 primes are correctly identified as probably prime
>> 2 - checking that a random sample of positive integers does not reveal non-prime numbers which test as prime
>> The test allows for specification of an alternate source file of prime numbers if one wants to run it by hand. The file of primes included in the patch was limited to 100000 values in the interest of keeping the file size small.
>> I think that the range of random numbers used for the non-prime portion of the test (currently [0,100000)) needs to be reexamined, but I wanted to throw this out there for discussion as-is.
>> I’ve extended the use of the j.u.stream API to the entire test as recommended by Paul in http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-October/021859.html.
>> Thanks,
>> Brian

More information about the core-libs-dev mailing list