PFGW 4.0.4 (with gwnum v30.10) Released - Page 8

TimSorbet · 2011-09-25, 18:21

Quote:

Originally Posted by rogue

I fixed a few bugs from 3.5.0 (ones that I introduced):

Fixed a bug in trivial factoring as primeserver would return 3 when calling the new ByIndex() function with a 1.
Fixed a bug with using ABC files and primorials as primeserver didn't re-initialize after processing the first line.
Fixed a bug with the p() and nextprime() functions when used in scripts.

I strongly recommend that you get 3.5.1 (which is still a beta BTW) in case you are trying to use 3.5.0.

Right now only the Windows build is available. I hope to get the Mac and Linux ones up later today.

I get a crash in 3.5.1, apparently when I use the p(n) function (from the command line, GUI, or from an ABC2 file). E.g. this makes it crash: "pfgw32 -q349*p(1)^5-1".

rogue · 2011-09-25, 20:02

Quote:

Originally Posted by Mini-Geek

I get a crash in 3.5.1, apparently when I use the p(n) function (from the command line, GUI, or from an ABC2 file). E.g. this makes it crash: "pfgw32 -q349*p(1)^5-1".

This is already fixed. 3.5.2 will be posted tomorrow.

rogue · 2011-09-27, 12:42

Quote:

Originally Posted by rogue

This is already fixed. 3.5.2 will be posted tomorrow.

I have posted 3.5.2 patching the known issues.

rogue · 2011-09-27, 15:27

A small bug was discovered in the nextprime function. I have re-released 3.5.2 to fix it. No other changes were made.

Batalov · 2011-09-30, 02:21

Oh, @#$!

I've used 3.5.0 with scr.txt to start a couple bases (R291, S381). They were royally screwed. A huge bunch of small composites (e.g. 2*291^1-1) "pass" both PRP and the N+1 test and get into pl_prime.txt.

Was this fixed in 3.5.2? I am switching back to 3.4.9, better safe than sorry. (of course, many of the k values that passed "as primes at n=1 with 3.5.0" get other small primes, but a significant portion don't; the whole script has to be rerun.)

rogue · 2011-10-08, 13:36

I've posted 3.5.5. Testing has shown that known problems are resolved. Batalov, can you do a little test to see if it works correctly for those two bases?

Batalov · 2011-10-08, 19:54

Will do.

Batalov · 2011-10-08, 21:00

Looks good now.

I tested on R291, S381 (so PRP and both N+1 and N-1 on small inputs were in use) - on linux64 and on Windows (both GUI and plain). The outputs were correct.

rogue · 2011-10-08, 22:58

Quote:

Originally Posted by Batalov

Looks good now.

I tested on R291, S381 (so PRP and both N+1 and N-1 on small inputs were in use) - on linux64 and on Windows (both GUI and plain). The outputs were correct.

Thanks.

Antonio · 2011-10-09, 07:38

Rogue,
There appears to be a bug in the command line option -f,
choose any value other than 100 and the software defaults to trial factoring to 4000000000 (tried 125, 110,95).
Using PFGW 3.5.5 win32 GUI
Command line: -f100 -tp in.txt
(wanted to use -f125)
Noticed when testing 19081#*2^19081-1

rogue · 2011-10-09, 13:17

Quote:

Originally Posted by Antonio

Rogue,
There appears to be a bug in the command line option -f,
choose any value other than 100 and the software defaults to trial factoring to 4000000000 (tried 125, 110,95).
Using PFGW 3.5.5 win32 GUI
Command line: -f100 -tp in.txt
(wanted to use -f125)
Noticed when testing 19081#*2^19081-1

Thanks for the bug report. I'll look into it.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
A possible bug in LLR/PFGW while using GWNUM (no bug in P95)	Batalov	Software	77	2015-04-14 09:01
PFGW 3.2.0 has been Released	rogue	Software	94	2010-09-14 21:39
PFGW 3.2.3 has been Released	rogue	Software	10	2009-10-28 07:07
PFGW 3.2.1 has been released	rogue	Software	5	2009-08-10 01:43
PFGW 3.1.0 has been Released	rogue	Software	25	2009-07-21 18:13

2011-09-27, 15:27	#81
rogue "Mark" Apr 2003 Between here and the 3·2,447 Posts	A small bug was discovered in the nextprime function. I have re-released 3.5.2 to fix it. No other changes were made.

2011-09-30, 02:21	#82
Batalov "Serge" Mar 2008 San Diego, Calif. 10100000011101₂ Posts	Oh, @#$! I've used 3.5.0 with scr.txt to start a couple bases (R291, S381). They were royally screwed. A huge bunch of small composites (e.g. 2*291^1-1) "pass" both PRP and the N+1 test and get into pl_prime.txt. Was this fixed in 3.5.2? I am switching back to 3.4.9, better safe than sorry. (of course, many of the k values that passed "as primes at n=1 with 3.5.0" get other small primes, but a significant portion don't; the whole script has to be rerun.)

2011-10-08, 13:36	#83
rogue "Mark" Apr 2003 Between here and the 7341₁₀ Posts	I've posted 3.5.5. Testing has shown that known problems are resolved. Batalov, can you do a little test to see if it works correctly for those two bases?

2011-10-08, 19:54	#84
Batalov "Serge" Mar 2008 San Diego, Calif. 3²×7×163 Posts	Will do.

2011-10-08, 21:00	#85
Batalov "Serge" Mar 2008 San Diego, Calif. 3²·7·163 Posts	Looks good now. I tested on R291, S381 (so PRP and both N+1 and N-1 on small inputs were in use) - on linux64 and on Windows (both GUI and plain). The outputs were correct.

2011-10-09, 07:38	#87
Antonio "Antonio Key" Sep 2011 UK 3²×59 Posts	Rogue, There appears to be a bug in the command line option -f, choose any value other than 100 and the software defaults to trial factoring to 4000000000 (tried 125, 110,95). Using PFGW 3.5.5 win32 GUI Command line: -f100 -tp in.txt (wanted to use -f125) Noticed when testing 19081#*2^19081-1