Pascal's OPN roadblock files - Page 99

henryzz · 2023-05-09, 19:53

Quote:

Originally Posted by kruoli

Do the 1500 files have no use for larger runs?

The composites in there will also be composites in larger runs. The 2000 file will also contain the same composites, and the counts will more accurately reflect larger runs.
The only disadvantage currently for the 2000 file is that I cut off the 2000 file at a count of 1000 due to the very large number of composites. I will likely lower that limit after the new runs, although there is the argument that we should be putting the majority of our effort into the composites with larger counts.

RichD · 2023-05-09, 20:14

And a few more.

Code:

5275839634902728677090008510552089
277490444914131700373476727483414543
69105295447793031045270905473403
1147716417489124081142455381681724219094063141371147373067
232950582970139704479984679901305761497008037325277883305237501

kruoli · 2023-05-09, 20:22

Quote:

Originally Posted by henryzz

The composites in there will also be composites in larger runs. The 2000 file will also contain the same composites, and the counts will more accurately reflect larger runs.
The only disadvantage currently for the 2000 file is that I cut off the 2000 file at a count of 1000 due to the very large number of composites. I will likely lower that limit after the new runs, although there is the argument that we should be putting the majority of our effort into the composites with larger counts.

In this case, I would like to re-think to query the whole factordb.com prime collection against the full file with optimised algorithms to try every number, even if it is used only once.

RichD · 2023-05-10, 03:52

A few more.

Code:

1598408960849668228766549680844915128224448888313
7864230223614414289919843708033
15175696574801740310794251270282912228859387511774265596194927
997139011835901179328949358224290308621

mataje · 2023-05-10, 06:53

c102-103 done.

RichD · 2023-05-10, 12:44

A few more. Now, on to some bigger jobs.

Code:

48933194480108817677705502090577559
83400475059333298007373143207921502566789
77884363793779341321174394999343003131
9681903143848472998057065605004348879972508680465444461
833586971040821558096338495071697338662103131

mataje · 2023-05-10, 16:54

c104-105 done.

RichD · 2023-05-10, 19:56

Quote:

Originally Posted by RichD

Now, on to some bigger jobs.

A couple jobs finished quickly before I realized I didn't have my working file sorted properly. Oh well, two more factors.

Code:

4524074983752574311223879499766345296419
2643528233172053376888556394576748277211

RichD · 2023-05-12, 01:19

A few more.

Code:

1721378999145613485535299240615964936170398544159611699259691728859402979
914269720501266921443858176747425465539419422463664389
3646994292679624434350084552840894234924876442310862210765844155072074429
608365163336375775508566157104883990727039
44958492339556697799083966525296817219445799627102853678719147
610213416486134737925026452012218053340512024691
1422132872927865514152901061041951
126175864040263260319994144183791

henryzz · 2023-05-12, 08:06

First rerun to 2000 finished
This run had 46,209,264 lines while the previous one had 57,260,812. This is a 19.3% reduction. I would imagine that the next run may be over 20% given that there are 741 new composites with counts >1k including some with counts in the high 10ks. Once I have factored a large proportion of these I will start the next run.

I am undecided at which count to cut off the next version of the files. There will be around 8k at >1000, 54k at >250, 154k >100 and 1.46m at >10. There really isn't much point in putting much effort into the very small counts as they don't take long to process. I am currently leaning towards sharing three file with cuts at 1000, 250 or 100 and 10. It may be worth removing factors <15 digits from the 10 file but more would be overkill and the middle file will need less than the 1000 file. Any opinions?
<=10 is more difficult for me to produce due to the very large size. Even >10 is irritatingly large.

mataje · 2023-05-12, 08:46

c106-107 done.

2023-05-10, 03:52	#1082
RichD Sep 2008 Kansas 59·67 Posts	A few more. Code: 1598408960849668228766549680844915128224448888313 7864230223614414289919843708033 15175696574801740310794251270282912228859387511774265596194927 997139011835901179328949358224290308621

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Passive Pascal	Xyzzy	GPU Computing	1	2017-05-17 20:22
Tesla P100 — 5.4 DP TeraFLOPS — Pascal	Mark Rose	GPU Computing	52	2016-07-02 12:11
Nvidia Pascal, a third of DP	firejuggler	GPU Computing	12	2016-02-23 06:55
Calculating perfect numbers in Pascal	Elhueno	Homework Help	5	2008-06-12 16:37
Factorization attempt to a c163 - a new Odd Perfect Number roadblock	jchein1	Factoring	30	2005-05-30 14:43

2023-05-12, 08:06	#1088
henryzz Just call me Henry "David" Sep 2007 Liverpool (GMT/BST) 3·23·89 Posts	First rerun to 2000 finished This run had 46,209,264 lines while the previous one had 57,260,812. This is a 19.3% reduction. I would imagine that the next run may be over 20% given that there are 741 new composites with counts >1k including some with counts in the high 10ks. Once I have factored a large proportion of these I will start the next run. I am undecided at which count to cut off the next version of the files. There will be around 8k at >1000, 54k at >250, 154k >100 and 1.46m at >10. There really isn't much point in putting much effort into the very small counts as they don't take long to process. I am currently leaning towards sharing three file with cuts at 1000, 250 or 100 and 10. It may be worth removing factors <15 digits from the 10 file but more would be overkill and the middle file will need less than the 1000 file. Any opinions? <=10 is more difficult for me to produce due to the very large size. Even >10 is irritatingly large.