Factoring small composites - Page 3

chris2be8 · 2020-11-16, 17:03

I've started running a script to add algebraic factors where they exist to factordb. I'm currently working from 88 to 90 digits. Which should thin down the junk a bit.

But this is getting rather annoying.

Chris

EdH · 2020-11-16, 17:33

This is what frustrates me away from providing my external elves. Currently, I'm hitting back pretty hard with a bunch of systems running from 70dd(+10) upwards. I'm showing a rate of a little over 6k/hr factored. I also have a couple Colab sessions working the same region.

In addition, I've got some RPi's and a separate Colab session working in the 40dd range to see what that does.

EdH · 2020-11-16, 17:46

Actually, it looks like for >69dd, we've caught back up to yesterday.

Am I treading on your algebraic factor work, Chris?

EdH · 2020-11-16, 19:43

It's gone to >1M <70 digit composites!

RichD · 2020-11-17, 02:24

I have been running in the 40dd and 50dd to find where my C2D laptop won't bust the hourly limits. It seems these number all have at least 10-12 or more factors!

EdH · 2020-11-17, 03:29

Quote:

Originally Posted by RichD

I have been running in the 40dd and 50dd to find where my C2D laptop won't bust the hourly limits. It seems these number all have at least 10-12 or more factors!

That explains why my Colab sessions weren't factoring 100%. I didn't look into why, but either YAFU wasn't returning factors less than 5 or 6 digits in size or my Python code wasn't retrieving them.

EdH · 2020-11-17, 17:09

Quote:

Originally Posted by RichD

I have been running in the 40dd and 50dd to find where my C2D laptop won't bust the hourly limits. It seems these number all have at least 10-12 or more factors!

Thank you! Because of what you posted, I revisited my RPi's that are only doing ECM. They had been registering <50% success in factoring, which seemed odd. I was starting the ECM runs with B1=11e2 and stopping with 11e5. I changed my start B1 to 11e1 and now I'm showing better than 90% success with composites at 10 digits + 100 (offset).

chris2be8 · 2020-11-17, 17:18

Quote:

Originally Posted by EdH

Am I treading on your algebraic factor work, Chris?

No, I've stopped that (there don't seem to be any left in this range).

Looking at a few in the 70+ digit range most of them seem to be from factordb running ECM against a large number and finding a composite factor (the product of most/all of the small factors). Just click "More information" and see what it says it's a factor of. It's probably true for the under 70 digit range as well.

I'm currently adding algebraic factors to numbers with status unknown. At present they nearly all seem to have algebraic factors. Just look at http://factordb.com/listtype.php?t=2

And I think the limits have been raised recently. Which is just as well given my 1 PC working from 70 to 79 digits seems to be factoring about 1 number per second!

Chris

chris2be8 · 2020-11-17, 17:22

If you have GP installed try something like:

Code:

echo 'factor($n,10^5)' | gp -f -q

That TFs a number up to 10^5 which is a much better way to split off small factors than running ECM.

Chris

EdH · 2020-11-17, 17:59

Quote:

Originally Posted by chris2be8

If you have GP installed try something like:

Code:

echo 'factor($n,10^5)' | gp -f -q

That TFs a number up to 10^5 which is a much better way to split off small factors than running ECM.

Chris

Thanks! I'll definitely try to set that up on my RPi machines.

But, my "farm" machines have almost all crashed! They were working 70dd+10 and they're all coming up with gibberish:

Code:

href="res.php">limits</a>) already factored
Error, no result found
Factoring 3 digits: (<a
compCheck                                     100%  127KB   9.8MB/s   00:00    
(<a already factored
(<a already factored
Error, no result found
Factoring 28 digits: href="imp.html">Imprint</a>)
compCheck                                     100%  127KB   9.7MB/s   00:00    
href="imp.html">Imprint</a>) already factored
Error, no result found
Factoring 3 digits: (<a
compCheck                                     100%  127KB   9.5MB/s   00:00    
(<a already factored
(<a already factored
Error, no result found
Factoring 31 digits: href="datenschutz.html">Privacy
compCheck                                     100%  127KB   9.3MB/s   00:00    
href="datenschutz.html">Privacy already factored
Error, no result found
Factoring 11 digits: Policy</a>)
compCheck                                     100%  127KB   9.6MB/s   00:00    
Policy</a>) already factored
Error, no result found
Factoring 0 digits: 
compCheck                                     100%  127KB   9.6MB/s   00:00    
 already factored
Error, no result found

(The compCheck is a file that contains a list of all the composites that any of the machines has factored, to minimize duplicates. I have to trim it often.)

I had to take the entire set down for now.

EdH · 2020-11-17, 19:30

Well, I've given up for now! I can't make my "farm" machines keep running for some reason. They all start out fine, but then spew junk after a few iterations. I guess the overwhelming small factors are somehow wrecking something. . .

I have the RPi's working in the 79dd+10 range, but nothing else. No Colab instances, either.

2020-11-17, 17:22	#31
chris2be8 Sep 2009 2²·3²·5·11 Posts	If you have GP installed try something like: Code: echo 'factor($n,10^5)' \| gp -f -q That TFs a number up to 10^5 which is a much better way to split off small factors than running ECM. Chris

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Is there a tool that picks off small composites constantly?	fivemack	FactorDB	14	2018-02-07 17:00
Command-line program for factoring small numbers	James Heinrich	Software	22	2011-08-29 16:35
What's the point of factoring known composites?	ixfd64	PrimeNet	4	2011-02-21 11:51
A small factoring program	Yamato	Factoring	2	2007-11-21 23:29
Factoring of composites with near factors - request for data	AntonVrba	Factoring	3	2006-02-05 06:30

2020-11-16, 17:03	#23
chris2be8 Sep 2009 2²×3²×5×11 Posts	I've started running a script to add algebraic factors where they exist to factordb. I'm currently working from 88 to 90 digits. Which should thin down the junk a bit. But this is getting rather annoying. Chris

2020-11-16, 17:33	#24
EdH "Ed Hall" Dec 2009 Adirondack Mtns 2²×3×5×59 Posts	This is what frustrates me away from providing my external elves. Currently, I'm hitting back pretty hard with a bunch of systems running from 70dd(+10) upwards. I'm showing a rate of a little over 6k/hr factored. I also have a couple Colab sessions working the same region. In addition, I've got some RPi's and a separate Colab session working in the 40dd range to see what that does.

2020-11-16, 17:46	#25
EdH "Ed Hall" Dec 2009 Adirondack Mtns 6724₈ Posts	Actually, it looks like for >69dd, we've caught back up to yesterday. Am I treading on your algebraic factor work, Chris?

2020-11-16, 19:43	#26
EdH "Ed Hall" Dec 2009 Adirondack Mtns 2²×3×5×59 Posts	It's gone to >1M <70 digit composites!

2020-11-17, 02:24	#27
RichD Sep 2008 Kansas 3240₁₀ Posts	I have been running in the 40dd and 50dd to find where my C2D laptop won't bust the hourly limits. It seems these number all have at least 10-12 or more factors!

2020-11-17, 19:30	#33
EdH "Ed Hall" Dec 2009 Adirondack Mtns 2²·3·5·59 Posts	Well, I've given up for now! I can't make my "farm" machines keep running for some reason. They all start out fine, but then spew junk after a few iterations. I guess the overwhelming small factors are somehow wrecking something. . . I have the RPi's working in the 79dd+10 range, but nothing else. No Colab instances, either.