Hello,

I have posted an updated patch here:

http://cr.openjdk.java.net/~bpb/8026236/webrev.01/

Thanks for your comments.

Brian

On Apr 23, 2014, at 7:28 AM, Peter Levart <peter.lev...@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
> 

Reply via email to