PFGW 3.8.3 (with gwnum v28.7) Released - Page 24

rogue · 2016-12-06, 23:52

Quote:

Originally Posted by rogue

Unless anyone asks otherwise, I am going to remove ABCZ (aka PrZ) file support in the next release. This is in the pfgw documentation:

Code:

     This is a highly compressed ABCD (or NewPGen) format file.  The file
     is compressed considerably more with the PrZ format, than it is with
     PkZip (or RAR/LHA/ACE2/SITX), and it is "processable" by PFGW in the 
     compressed form.  At this writing, the PrZ format is still a work in 
     progress, so the code itself will (may) change some.

I don't think that file sizes are much of a concern today (compared to more than 10 years ago when this code was written).

I got a request to keep this feature, so I will not remove it.

pepi37 · 2016-12-15, 19:53

It looks like I found bug in latest PFGW 3.8.3

To summarize: I was start srbsieve with latest PFGW 3.8.3 on base 2017 (just for fun). Immediately, when srbsieve send candidates to PFGW , he crash
So I take 3.7.10 version of PFGW, and it works perfect.
In 7.z file is log files, and srbiseve ini, so you can verify yourself
OS is Win 7 x64

rogue · 2016-12-15, 20:16

Quote:

Originally Posted by pepi37

It looks like I found bug in latest PFGW 3.8.3

To summarize: I was start srbsieve with latest PFGW 3.8.3 on base 2017 (just for fun). Immediately, when srbsieve send candidates to PFGW , he crash
So I take 3.7.10 version of PFGW, and it works perfect.
In 7.z file is log files, and srbiseve ini, so you can verify yourself
OS is Win 7 x64

That is probably due to a bug I introduced for this feature. I have been lazy about ensuring that the latest version fixes the problem. I'll do that in the next few days.

pepi37 · 2016-12-15, 20:18

Ok, thanks for reply!

rogue · 2016-12-16, 01:18

I have updated sourceforge with the current Windows build. AFAICT, the problem you experienced is fixed.

J F · 2016-12-16, 22:37

The new version also seem to fix the bug with decimal
format 'Length is beyond length of decimal on line 1Length...'

Thanks!

pepi37 · 2016-12-16, 23:07

Thanks!
Works perfectly!

rogue · 2016-12-17, 03:37

Quote:

Originally Posted by J F

The new version also seem to fix the bug with decimal
format 'Length is beyond length of decimal on line 1Length...'

Thanks!

There was a length limit to the DECIMAL file format which you were probably exceeding. I bumped it up with this release.

pepi37 · 2017-01-19, 23:29

New bug in PFGW ( but only in WinPFGW, not in console version)

Input data is

(8*10^1035622-1)%957096645713241
(8*10^1036567-1)%526612985592801
(8*10^1037351-1)%215554484612681
(8*10^1037915-1)%345760807642879
(8*10^1038217-1)%9712423347241061
(8*10^1038529-1)%58955826639041

Console output ( and that is correct one- same on linux)

Switching to Exponentiating using GMP
(8*10^1035622-1)%957096645713241 is composite: RES64: [00011B662B4EE19F] (0.0001s+0.0266s)
(8*10^1036567-1)%526612985592801 is composite: RES64: [0001042357D1FCAF] (0.0000s+0.0273s)
(8*10^1037351-1)%215554484612681 is composite: RES64: [00000000000002D9] (0.0000s+0.0260s)
(8*10^1037915-1)%345760807642879 is Zero (0)
(8*10^1038217-1)%9712423347241061 is Zero (0)
(8*10^1038529-1)%58955826639041 is Zero (0)

WinPFGW

Switching to Exponentiating using GMP
(8*10^1037915-1)%345760807642879 is Zero (0)
(8*10^1038217-1)%9712423347241061 is Zero (0)
(8*10^1038529-1)%58955826639041 is Zero (0)
(8*10^1038785-1)%22384719218236939 is Zero (0)
(8*10^1039240-1)%13542862267545593 is Zero (0)
(8*10^1039279-1)%16824139280551174082239 is Zero (0)

but data in output file is correct

(8*10^1035622-1)%957096645713241 is composite: RES64: [00011B662B4EE19F] (0.0001s+0.0278s)
(8*10^1036567-1)%526612985592801 is composite: RES64: [0001042357D1FCAF] (0.0000s+0.0281s)
(8*10^1037351-1)%215554484612681 is composite: RES64: [00000000000002D9] (0.0000s+0.0286s)
(8*10^1037915-1)%345760807642879 is Zero (0)
(8*10^1038217-1)%9712423347241061 is Zero (0)
(8*10^1038529-1)%58955826639041 is Zero (0)
(8*10^1038785-1)%22384719218236939 is Zero (0)

paulunderwood · 2017-01-20, 00:14

I don't see a bug. Clearly suppressing such output in Win-PFGW is an advantage as it would otherwise slow down calculation!

pepi37 · 2017-01-20, 12:39

Quote:

Originally Posted by paulunderwood

I don't see a bug. Clearly suppressing such output in Win-PFGW is an advantage as it would otherwise slow down calculation!

Dont agree with you: will program write it is zero or it has RES, calculation speed is same.

2016-12-16, 01:18	#258
rogue "Mark" Apr 2003 Between here and the 2·3²·353 Posts	I have updated sourceforge with the current Windows build. AFAICT, the problem you experienced is fixed. Last fiddled with by rogue on 2016-12-16 at 01:18

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.2 has been Released	rogue	Software	20	2009-08-23 12:14
PFGW 3.2.1 has been released	rogue	Software	5	2009-08-10 01:43

2016-12-15, 20:18	#257
pepi37 Dec 2011 After milion nines:) 1451₁₀ Posts	Ok, thanks for reply!

2016-12-16, 22:37	#259
J F Sep 2013 56₁₀ Posts	The new version also seem to fix the bug with decimal format 'Length is beyond length of decimal on line 1Length...' Thanks!

2016-12-16, 23:07	#260
pepi37 Dec 2011 After milion nines:) 10110101011₂ Posts	Thanks! Works perfectly!

2017-01-19, 23:29	#262
pepi37 Dec 2011 After milion nines:) 5AB₁₆ Posts	New bug in PFGW ( but only in WinPFGW, not in console version) Input data is (810^1035622-1)%957096645713241 (810^1036567-1)%526612985592801 (810^1037351-1)%215554484612681 (810^1037915-1)%345760807642879 (810^1038217-1)%9712423347241061 (810^1038529-1)%58955826639041 Console output ( and that is correct one- same on linux) Switching to Exponentiating using GMP (810^1035622-1)%957096645713241 is composite: RES64: [00011B662B4EE19F] (0.0001s+0.0266s) (810^1036567-1)%526612985592801 is composite: RES64: [0001042357D1FCAF] (0.0000s+0.0273s) (810^1037351-1)%215554484612681 is composite: RES64: [00000000000002D9] (0.0000s+0.0260s) (810^1037915-1)%345760807642879 is Zero (0) (810^1038217-1)%9712423347241061 is Zero (0) (810^1038529-1)%58955826639041 is Zero (0) WinPFGW Switching to Exponentiating using GMP (810^1037915-1)%345760807642879 is Zero (0) (810^1038217-1)%9712423347241061 is Zero (0) (810^1038529-1)%58955826639041 is Zero (0) (810^1038785-1)%22384719218236939 is Zero (0) (810^1039240-1)%13542862267545593 is Zero (0) (810^1039279-1)%16824139280551174082239 is Zero (0) but data in output file is correct (810^1035622-1)%957096645713241 is composite: RES64: [00011B662B4EE19F] (0.0001s+0.0278s) (810^1036567-1)%526612985592801 is composite: RES64: [0001042357D1FCAF] (0.0000s+0.0281s) (810^1037351-1)%215554484612681 is composite: RES64: [00000000000002D9] (0.0000s+0.0286s) (810^1037915-1)%345760807642879 is Zero (0) (810^1038217-1)%9712423347241061 is Zero (0) (810^1038529-1)%58955826639041 is Zero (0) (8*10^1038785-1)%22384719218236939 is Zero (0)

2017-01-20, 00:14	#263
paulunderwood Sep 2002 Database er0rr 2·3²·11·19 Posts	I don't see a bug. Clearly suppressing such output in Win-PFGW is an advantage as it would otherwise slow down calculation!