Very Prime Riesel and Sierpinski k - Page 39

robert44444uk · 2012-03-15, 07:28

And the Riesel E28 table - truly underdeveloped:

Code:

1	1	6191	R	28
2	2	137805	R	28
3	3	228483	R	28
4	4	874415	R	28
5	5	874415	R	28
6	6	2972625	R	28
7	7	98776429	R	28
8	8	72167913	R	28
9	9	688241231	R	28
10	10	7915539463	R	28
11	12	709602395	R	28
12	13	709602395	R	28
13	15	7482142653	R	28
14	17	39984233659	R	28
15	18	39984233659	R	28
16	19	39984233659	R	28
17	23	3428771	R	28
18	28	1159606077	R	28
19	33	17427384519	R	28
20	42	26803514639	R	28
21	45	11498712013	R	28
22	49	199281	R	28
23	54	199281	R	28
24	60	46909222367	R	28
25	66	46909222367	R	28
26	73	46909222367	R	28
27	76	19235069	R	28
28	81	19235069	R	28
29	88	11889667797	R	28
30	90	11889667797	R	28
31	101	11889667797	R	28
32	109	19235069	R	28
33	110	19235069	R	28
34	112	19235069	R	28
35	125	19235069	R	28
36	132	19235069	R	28
37	135	19235069	R	28
38	137	19235069	R	28
39	142	19235069	R	28
40	151	19235069	R	28
41	160	19235069	R	28
42	174	19235069	R	28
43	191	19235069	R	28
44	225	19235069	R	28
45	227	19235069	R	28
46	259	19235069	R	28
47	313	19235069	R	28
48	326	19235069	R	28
49	374	33575827	R	28
50	406	33575827	R	28
51	454	19235069	R	28
52	461	33575827	R	28
53	501	8316321	R	28
54	503	8316321	R	28
55	517	8316321	R	28
56	552	8316321	R	28
57	554	8316321	R	28
58	597	8316321	R	28
59	628	8316321	R	28
60	635	8316321	R	28
61	738	46613551	R	28
62	780	46613551	R	28
63	807	46613551	R	28
64	839	46613551	R	28
65	907	46613551	R	28
66	991	8316321	R	28
67	1052	8316321	R	28
68	1245	8316321	R	28
69	1373	8316321	R	28
70	1491	8316321	R	28
71	1537	46613551	R	28
72	1594	8316321	R	28
73	1669	8316321	R	28
74	1735	8316321	R	28
75	1746	8316321	R	28
76	2410	46613551	R	28
77	2482	8316321	R	28
78	2817	34794485	R	28

pinhodecarlos · 2012-03-15, 08:14

Quote:

Originally Posted by robert44444uk

I would like to reserve Riesel E36 iteration 10...I'm assuming that Carlos is already looking at some iterations, hopefully this won't be an overlap.

No, I am not running Riesel E36.

Thomas11 · 2012-03-15, 09:14

Quote:

Originally Posted by robert44444uk

A couple of pointers for the programming:

On both my computers I got the error message msvcr100.dll missing. I solved it on my vista by copying and renaming msvcr100_clr0400.dll to the required name.

On my older machine I have a variety of msvcr files, but they are only numbered up to 90.

Thanks for pointing this out. I wasn't aware of this problem.
Please test the version attached. It should only depend on msvcr90.dll.

robert44444uk · 2012-03-15, 09:22

I have been corresponding off-forum with Thomas11 on what to do about higher E.

There is a huge gap between E226 and E268 as there are many additional primes that have to be considered in the CR. There are 20 primes smaller than 10,000 with modulos between E226 and E268.

So unsurprisingly, we have found no Riesel or Sierpinski E268 despite running hundreds of cycles on each side.

Perhaps the quickest way to generate E268 would use the formula y=z*269#/2, where 269# is the primorial, z an integer variable. It is certainly not as elegant as the traditional way of generating Payam numbers, as key primes such as 7, 17, 23 etc are eliminated in the primorial rather than the CRT.

Then all you would have to do is to run a CR on integers z, to eliminate all 10000>p>269 (say) where their modular order base 2 is <269 - call these "Q1" primes. Candidates falling out here would then be tested for Q2 primes where p>10000. It should be possible to generate E268s as fast as we generate E100s I think, using this method.

Alternatively, we could adopt a concept I have used before of slightly deficient primorials, in this way, the efficiency of the eventual k are increased. Here the base form for which z would be subject to the CRT would be y=z*269#/(2*7*17*23...w), where w depends on how far you want to make the primorial deficient. The 7,17,23...w are instead loaded into the CR calculation, alongside the Q1 primes. The eventual k are 7, 119, 2737... times smaller than their primorial counterparts, and should be therefore more prime on average.

If we can generate, say, 20 to 30 E268 a second using this, then we can perhaps use the part of Robert G's software that does the prime checking, with Smith checks to take out the hopeless cases.

This approach would also allow us to look at much higher E

Grateful for views on how feasible this all is to program and if there are any volunteers.

robert44444uk · 2012-03-15, 09:49

Quote:

Originally Posted by robert44444uk

Perhaps the quickest way to generate E268 would use the formula y=z*269#/2, where 269# is the primorial, z an integer variable. It is certainly not as elegant as the traditional way of generating Payam numbers, as key primes such as 7, 17, 23 etc are eliminated in the primorial rather than the CRT.
....

Alternatively, we could adopt a concept I have used before of slightly deficient primorials, in this way, the efficiency of the eventual k are increased. Here the base form for which z would be subject to the CRT would be y=z*269#/(2*7*17*23...w), where w depends on how far you want to make the primorial deficient. The 7,17,23...w are instead loaded into the CR calculation, alongside the Q1 primes. The eventual k are 7, 119, 2737... times smaller than their primorial counterparts, and should be therefore more prime on average.

A little more thinking about using deficient primorials versus primorials.

There is a tradeoff of complexity, every time a prime is used in the CR the complexity increases and the candidate numbers will be harder to find. If primes are to be taken out of the primorial then they should have low modulo base 2 compared to their p value, as the complexity (I think) in the CR increases if the modulo value is high.

If this is the case, then the primes to remove from the primorial would be in the following order:

Code:

p      modulo
127	7
257	16
151	15
241	24
73	9
89	11
233	29
31	5
223	37
251	50
113	28

Removing the first 4 provides for E268 which are a billion times smaller than their primorial counterparts, while using all provides at 10^23 pickup.

robert44444uk · 2012-03-15, 10:01

Quote:

Originally Posted by Thomas11

Thanks for pointing this out. I wasn't aware of this problem.
Please test the version attached. It should only depend on msvcr90.dll.

This works, thank you!

Thomas11 · 2012-03-15, 11:59

I'm currently running some tests on E=226 (Sierpinski side).

The speed-up after just a few iterations is just exciting:

For the older code (payam.c) I've got about 5 iterations per hour.
But the new code (payam2.c) yields 2 iterations per minute!

pinhodecarlos · 2012-03-15, 12:19

Quote:

Originally Posted by Thomas11

I'm currently running some tests on E=226 (Sierpinski side).

The speed-up after just a few iterations is just exciting:

For the older code (payam.c) I've got about 5 iterations per hour.
But the new code (payam2.c) yields 2 iterations per minute!

For E=66 Riesel side, and after 12 hours of testing, the new code is about 1.38 times faster than the old one.
Thank you Robert G for the new code and Thomas for the binaries!!

robert44444uk · 2012-03-15, 12:24

Confirmed, amazing pickup as well on the Riesel E226 side.

Did a couple of hours of E28 and E36 just to test it out. 1 absolute record (Sierpinski or Riesel) found in just that amount of time

15 17 29958874375317 R 28

But I will now move to E226 and E268 on two cores.

pinhodecarlos · 2012-03-15, 12:37

Thomas,

The latest 64-bit version binary is optimized for Core2 or for Nehalem" cpu architecture?

Carlos

EDIT: My question follows the comparison speed I made. I don't get as much as speed up as you get probably because I am comparing two different optimized clients. I was running the old code using the Nehalem binary...and I suppose the new binary is core2 based.

Thomas11 · 2012-03-15, 13:07

Quote:

Originally Posted by pinhodecarlos

The latest 64-bit version binary is optimized for Core2 or for Nehalem" cpu architecture?

The binaries were optimized for Core2 (64 bits) and P4 (32 bits).

A "Nehalem" version is attached, but note that I don't have a Nehalem machine here for testing...

It would be nice if you could do some comparative test of the Core2 and Nehalem binaries, e.g. using the same input files (just a few sub-iterations).

2012-03-15, 12:37	#428
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 1001101010011₂ Posts	Thomas, The latest 64-bit version binary is optimized for Core2 or for Nehalem" cpu architecture? Carlos EDIT: My question follows the comparison speed I made. I don't get as much as speed up as you get probably because I am comparing two different optimized clients. I was running the old code using the Nehalem binary...and I suppose the new binary is core2 based. Last fiddled with by pinhodecarlos on 2012-03-15 at 13:05

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Semiprime and n-almost prime candidate for the k's with algebra for the Sierpinski/Riesel problem	sweety439	sweety439	11	2020-09-23 01:42
Dual Sierpinski/Riesel prime	sweety439	Conjectures 'R Us	0	2016-12-07 15:01
Sierpinski/ Riesel bases 6 to 18	robert44444uk	Conjectures 'R Us	139	2007-12-17 05:17
Sierpinski/Riesel Base 10	rogue	Conjectures 'R Us	11	2007-12-17 05:08
Sierpinski / Riesel - Base 22	michaf	Conjectures 'R Us	49	2007-12-17 05:03

2012-03-15, 09:22	#422
robert44444uk Jun 2003 Oxford, UK 3×11×59 Posts	I have been corresponding off-forum with Thomas11 on what to do about higher E. There is a huge gap between E226 and E268 as there are many additional primes that have to be considered in the CR. There are 20 primes smaller than 10,000 with modulos between E226 and E268. So unsurprisingly, we have found no Riesel or Sierpinski E268 despite running hundreds of cycles on each side. Perhaps the quickest way to generate E268 would use the formula y=z269#/2, where 269# is the primorial, z an integer variable. It is certainly not as elegant as the traditional way of generating Payam numbers, as key primes such as 7, 17, 23 etc are eliminated in the primorial rather than the CRT. Then all you would have to do is to run a CR on integers z, to eliminate all 10000>p>269 (say) where their modular order base 2 is <269 - call these "Q1" primes. Candidates falling out here would then be tested for Q2 primes where p>10000. It should be possible to generate E268s as fast as we generate E100s I think, using this method. Alternatively, we could adopt a concept I have used before of slightly deficient primorials, in this way, the efficiency of the eventual k are increased. Here the base form for which z would be subject to the CRT would be y=z269#/(2717*23...w), where w depends on how far you want to make the primorial deficient. The 7,17,23...w are instead loaded into the CR calculation, alongside the Q1 primes. The eventual k are 7, 119, 2737... times smaller than their primorial counterparts, and should be therefore more prime on average. If we can generate, say, 20 to 30 E268 a second using this, then we can perhaps use the part of Robert G's software that does the prime checking, with Smith checks to take out the hopeless cases. This approach would also allow us to look at much higher E Grateful for views on how feasible this all is to program and if there are any volunteers.

2012-03-15, 11:59	#425
Thomas11 Feb 2003 2²×3²×53 Posts	I'm currently running some tests on E=226 (Sierpinski side). The speed-up after just a few iterations is just exciting: For the older code (payam.c) I've got about 5 iterations per hour. But the new code (payam2.c) yields 2 iterations per minute!

2012-03-15, 12:24	#427
robert44444uk Jun 2003 Oxford, UK 79B₁₆ Posts	Confirmed, amazing pickup as well on the Riesel E226 side. Did a couple of hours of E28 and E36 just to test it out. 1 absolute record (Sierpinski or Riesel) found in just that amount of time 15 17 29958874375317 R 28 But I will now move to E226 and E268 on two cores.