Pascal's OPN roadblock files

[kruoli]

A good way to sort them alternatively would be to sort them by "worth per CPU time", if feasible.

Cuts down to 100 seem enough right now, under that I would only include very small effort numbers.

I would rather take 11 numbers with 100 occurrences each than 1 with 1000 occurrence, if the latter takes 10 times than the former 11 combined. But am I right that the former is helping more than the latter?

[henryzz]

Originally Posted by kruoli

A good way to sort them alternatively would be to sort them by "worth per CPU time", if feasible.

Cuts down to 100 seem enough right now, under that I would only include very small effort numbers.

I would rather take 11 numbers with 100 occurrences each than 1 with 1000 occurrence, if the latter takes 10 times then the former 11 combined. But am I right that the former is helping more than the latter?

I think assuming that factoring 10 numbers with 100 occurrences has a similar value to 1 number with 1000 occurrences is probably not too far off.
That said, I think I would probably bias towards the larger number of occurrences as factorising a larger composite is more likely to resolve the branch they are on quickly than a smaller composite. Also, small composites are more likely to be made less useful by a higher count composite earlier in the branch being factored.

I think the key is proportional effort. There are some very small composites(< 30 digits) with a count of 11 that would be almost trivial to factor. Finding small factors(10-15 digits) of a bit larger composites(70-90 digits) is probably also sensible. Where to draw the line is the hard question.

What I might do is release a >1000 file and a 100-1000 file and then put some limited effort into 11-100 myself.

[mataje]

c108 done.

[RichD]

A few more.

53221332898700931181927750710809982608278875204119451499289793176845749029
71673642604337536910318592333935265192958709330939
580207031333413530991752957821431025223538035053
86042732058684658360669780925056604344851185892397786553
108744644320040345222031034029744682222492938561064723
11247032907871281997202334234705852359518901860024609009
11753110781526756963000476176648060297086467446188713
871501772310322209816125739630641514928554583203155946859161605649984943475447017

[henryzz]

Originally Posted by mataje

c108 done.

Might be worth considering SNFS soon for some of these numbers if you aren't already.

[mataje]

Originally Posted by henryzz

Might be worth considering SNFS soon for some of these numbers if you aren't already.

Yes, I'm doing SNFS.

c109 done.

[mataje]

c110 done.

[RichD]

A few more.

1163655092971708860163950657011
26872795242136158441670542851253308225992283
116871637472761353354477269344041264194234012305237868914769
2555196008871276741365602739295937787836636597
2097002968798683666641295419851
6780151420689585119941845325650354148259329
7698766669209427009208820741789363380935139
11053402943458280285379613826308745198177714348686216470725021277676259
4083447645543359365296494678197987871176057928559473060041187077540003738186342279817295131543

[mataje]

c111 done.

[henryzz]

My second rerun has now finished. This run had 45,664,393 lines, while the previous one had 57,260,812. This is a 20.3% reduction.

I have uploaded two sets of files to https://drive.google.com/drive/folde...-s?usp=sharing
A medium file which contains numbers with counts from 100-999 and a large file with counts 1000+. Like the previous files I have created restricted versions which don't include composites from the t2200 file because these have received a significant amount of ecm in the past.
Very little effort has been put into these numbers(unless they appeared in the previous file). There should be no factors below 10M.

[mataje]

A few of c112.
Now im working with rc_2000_restricted_r2_large. c16-49 done.