PRPNet 3.0.0 Released

[rogue]

Originally Posted by Mini-Geek

I made this mod to SierpinskiRieselHTML.cpp lines 124 and 125: (new code bold)

      theSocket->Send("<tr %s><td align=center  colspan=10>%d of %d have primes/PRPs (%d remaining)</tr>",
                      (kCount == primeCount ? "bgcolor=\"red\"" : ""),  primeCount, kCount, kCount-primeCount);

Just putting it here to see if you think it'd be a good permanent addition. (I know that it's only marginally useful for things like large Sierp/Riesel work, since the number of primes there are usually 0 or 1, but it's not at a high readability cost or anything; and if that was really a big problem, you could make it only appear when there are at least 5 primes, or something like that; it is useful for smaller work, where there are usually many k's and primes)

Sometimes the server will just stop working. I didn't have detailed logging at the time, so nothing significant appeared (I turned full logging on a while ago, but of course since then it's stopped doing it ), but here are the symptoms:
no clients can connect,
using Ctrl+C to try to end it prints the message saying it's trying to close, but it doesn't (at least not for how long I've waited).
Killing the process with Task Manager works, and when I start it again, it all works just fine.

I can make that change.

I did find a couple of bugs that could be related to that problem. I'll fix them in 3.2.3.

[Mini-Geek]

Unless I'm mistaken, the formula for calculating decimal lengths currently rounds the result instead of taking floor(result)+1 like it should. This would be a simple fix that would change the results from "approximately" to exactly (at least for k*b^n+c and GFN types of work; I don't know if the factorials/primorials might still be inexact due to some other thing).

[rogue]

Originally Posted by Mini-Geek

Unless I'm mistaken, the formula for calculating decimal lengths currently rounds the result instead of taking floor(result)+1 like it should. This would be a simple fix that would change the results from "approximately" to exactly (at least for k*b^n+c and GFN types of work; I don't know if the factorials/primorials might still be inexact due to some other thing).

I believe that you are correct. It has been fixed.

[rogue]

I have put an alpha for 3.2.3 here:

http://home.roadrunner.com/~mrodenki...pnet_3.2.3.zip

I have not gone through any of the heavy duty testing for NPLB, but there are enough other improvements that people have been waiting for. Here is a summary of the changes:

All executables:

• Fixed a crash that can occur if the socket connection is lost when sending data across it.

Server only:

• Fixed SQL so that GFN divisors are inserted into the database.
• Fixed two issues that could lead to the server looping when a client requests work.
• Added new debug messages when fetching from a cursor.
• Change format of messages in completed_tests.log to match formatting from 3.2.0.
• Added sortoption=A, sorting by oldest candidate.

Thanks to help from Lennart and John over at PrimeGrid, this release has (so far) proven to be handle heavy loads on Ubuntu. I'll try to do some more testing as soon as I can. I would like to get this release to beta status.

[Mini-Geek]

// unhideprimehours= is the number of hours to wait before and primes/PRPs
// will be available on the user_primes.html webpage.  When set to 0 (the
// default), it could take up to 10 minutes before they are shown.
unhideprimehours=0

Currently, whether a prime is actually displayed is controlled by the ShowOnWebPage field of the UserPrimes table (as updated every unhideprimehours hours and 10 minutes).
Wouldn't it be just as easy (and fix the known bug of it not showing new primes right away) to not have that field at all, and just calculate the time difference from the DateReported field when you need to decide if it should display? (i.e. when it's generating the page listing primes)
Or, instead of that, just make it so when generating the page listing primes, it first runs the UnhidePrimes code to unhide any primes that should no longer be hidden.

[rogue]

Originally Posted by Mini-Geek

// unhideprimehours= is the number of hours to wait before and primes/PRPs
// will be available on the user_primes.html webpage.  When set to 0 (the
// default), it could take up to 10 minutes before they are shown.
unhideprimehours=0

Currently, whether a prime is actually displayed is controlled by the ShowOnWebPage field of the UserPrimes table (as updated every unhideprimehours hours and 10 minutes).
Wouldn't it be just as easy (and fix the known bug of it not showing new primes right away) to not have that field at all, and just calculate the time difference from the DateReported field when you need to decide if it should display? (i.e. when it's generating the page listing primes)
Or, instead of that, just make it so when generating the page listing primes, it first runs the UnhidePrimes code to unhide any primes that should no longer be hidden.

I have modified the behavior of this in 3.2.4. If set to 0 it will be shown immediately.

[rogue]

I have put an alpha for 3.2.4 here:

http://home.roadrunner.com/~mrodenki...pnet_3.2.4.zip

There are a lot of changes to this release, but they are relatively minor. Some are bug fixes and others are enhancements that have been requested. Here is a list of changes:

Client only:

• Skip workunits on Sierpinski/Riesel type servers on matching k/b/c with higher n if a prime/PRP is found.
• Use -gxo instead of -gx when searching for GFN divisors since primality test has already been done.
• This release of PRPNet requires PFGW 3.3.4 if used on any projects that can test for GFN divisibility. PFGW 3.3.4 outputs a string that the client requires before it can tell the server that it has successfully tested for GFN divisors.

Server only:

• Added code for loading GFNs from an ABC file. Somehow I had overlooked it.
• Added abcformats.txt to describe supported ABC formats.
• Have server send out tests for lower n on Sierpinski/Riesel servers even if a prime/PRP is found for a higher n.
• If a Sierpinski/Riesel prime is found, then do not count candidates with a higher n against the "untested candidates" count on the server stats page.
• Fixed an issue that prevented double checks from being correctly updated in the database.
• Fixed e-mail message for Proth numbers to state that client searched for GFN divisors, but did not find any instead of saying that search wasn't done.
• Fixed console output issue when PRP is found.
• Fixed server_stats.html for FixedBNC servers.
• Modified columns on CandidateGroupStats to work with FixedBNC servers. Use the following statements to modify the columns:
  
  alter table CandidateGroupStats modify MinInGroup varchar(20);
  alter table CandidateGroupStats modify MaxInGroup varchar(20);
  alter table CandidateGroupStats modify LeadingEdge varchar(20);

This will probably be the last release that will support the upgrade option from a 2.x PRPNet. I haven't made a final decision on that, but the stability of 3.2.3 show give anyone running an 2.x release good reason to upgrade.

--Mark

[rogue]

I have put an alpha for 3.2.5 here:

http://home.roadrunner.com/~mrodenki...pnet_3.2.5.zip

I ran into a bug in the client with Sierpinski/Riesel servers. It was getting stuck in a loop after a prime/PRP was found.

[MyDogBuster]

146226*105^18627+1 and 71816*105^21594+1 are both PRP but NOT prime.

Why did PRPNET 2.4.5 server and client remove remaining tests for those k's from the candidates file?

CLLR and PFGW BOTH test those expressions out as PRP but not prime.

[mdettweiler]

Originally Posted by MyDogBuster

146226*105^18627+1 and 71816*105^21594+1 are both PRP but NOT prime.

Why did PRPNET 2.4.5 server and client remove remaining tests for those k's from the candidates file?

CLLR and PFGW BOTH test those expressions out as PRP but not prime.

Perhaps they're simply the biggest composite PRPs on record? Hmm, well, they both are proven prime easily when I run them through my local copy of PFGW (v3.3.3) with -t:

Primality testing 146226*105^18627+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 2
Calling Brillhart-Lehmer-Selfridge with factored part 41.81%
146226*105^18627+1 is prime! (46.3561s+0.0640s)

Primality testing 71816*105^21594+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 11
Calling Brillhart-Lehmer-Selfridge with factored part 41.81%
71816*105^21594+1 is prime! (70.2824s+0.0035s)

[MyDogBuster]

Perhaps they're simply the biggest composite PRPs on record? Hmm, well, they both are proven prime easily when I run them through my local copy of PFGW (v3.3.3) with -t:

Primality testing 146226*105^18627+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 2
Calling Brillhart-Lehmer-Selfridge with factored part 41.81%
146226*105^18627+1 is prime! (46.3561s+0.0640s)

Primality testing 71816*105^21594+1 [N-1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 11
Calling Brillhart-Lehmer-Selfridge with factored part 41.81%
71816*105^21594+1 is prime! (70.2824s+0.0035s)

Hmmmm I ran them thru PFGW. I'll recheck. Thanks Max