Factoring small composites - Page 2

EdH · 2020-11-02, 19:28

I'm going to bring this thread back to life to address the ongoing (elves) work for the db.

I referenced in an aliquot thread my current work with small fdb composites and I'd like to move that discussion to this thread. If Chris2be8 is agreeable I may move our relevant posts from there to here later on.

Currently I am running a couple Colab instances at 91 dd, but they are under-performing. Evaluating the backlog for even the 7x digit composites, I'm thinking of lowering my work down into that area. I'm using a pretty large random, so my duplication rate will hopefully be minimal. If anyone would like me to move higher and leave some "smaller fruit," don't be shy letting me know. I could easily work at 8x dd or higher, but I'm running ECM with some RPi's and a couple of my Colab sessions; one with YAFU and the other using the GPU branch of GMP-ECM and Msieve.

EdH · 2020-11-03, 19:12

Base 162 table should be all "greened up" now.

I've started "touching" all the sequences for the tables and it took a couple hours to do five tables this morning. I have started a script to run all of the tables except 220 and 284, since they're just being initialized and probably won't need any "help." I'm curious how long the script will actually take to get through everything.

EdH · 2020-11-04, 13:53

I was greeted this morning with the finished script, so every sequence in the current tables and base 72, has been accessed. Hopefully, that will get the update time back near normal.

richs · 2020-11-04, 14:22

I have had one core of an i3 running the perl script utilizing yafu for the past 6 months or so. It is set to start at C81 and to choose one of the first 1,000 composites, so I have not had much problem with worker collisions.

EdH · 2020-11-04, 15:47

Quote:

Originally Posted by richs

I have had one core of an i3 running the perl script utilizing yafu for the past 6 months or so. It is set to start at C81 and to choose one of the first 1,000 composites, so I have not had much problem with worker collisions.

I've got everything running from 76 upward with 1000 random as well. I have three RPi's running 24/7, a Core2 Duo running about 11hr/day and I've been running a couple Colab YAFU sessions per day recently. At this size the Colab sessions are doing better than 1000 per day, each.

I suppose I will catch up to your size pretty soon. If you do notice collisions, mention it here and I'll hop a little higher. I might do that anyway. . .

chris2be8 · 2020-11-04, 16:56

@EdH, you are welcome to move my last 2 posts from the aliquot thread here, I was only using it as a place to let off steam about the amount of junk being added to factordb.

I've got one system working from 70-79 digits, it grabs the smallest number in that range, factors it and repeats. So if you want to work in that range taking an offset of 10+rand(1000) would make absolutely sure you would not collide with me.

I'm also working on 80+ digit numbers that can be factored by SNFS. I'm currently working around 84 digits (I was at 90 digits until recently). These are spaced out enough to make collisions unlikely.

And thanks for the help.

Chris

EdH · 2020-11-04, 18:50

Quote:

Originally Posted by chris2be8

@EdH, you are welcome to move my last 2 posts from the aliquot thread here, I was only using it as a place to let off steam about the amount of junk being added to factordb.

I've got one system working from 70-79 digits, it grabs the smallest number in that range, factors it and repeats. So if you want to work in that range taking an offset of 10+rand(1000) would make absolutely sure you would not collide with me.

I'm also working on 80+ digit numbers that can be factored by SNFS. I'm currently working around 84 digits (I was at 90 digits until recently). These are spaced out enough to make collisions unlikely.

And thanks for the help.

Chris

Thanks Chris, The posts have been moved (and, mine copied/edited) and I have added the offset to all my local machines and the two Colab setups.

I'm looking at the feasibility of adding some scripts to my main ecmpi/CADO-NFS clients, to use them as elves when the CADO-NFS servers are doing LA. But, I'm not sure if/when I may do that. I have been away from elf work because I got really frustrated by the huge composite dump that happened right after we had cleared out the backlog through 100 (or, maybe it was even 110) digits. I'm a little encouraged ATM, with the actual overall number of composites through 120 showing a decrease instead of still growing.

EdH · 2020-11-15, 19:41

>40,000 composites added to the <70 queue?

@Chris: Do I remember you helping out the db when it gets this type of flooding? Should I turn a Colab session against them? Or, will this be a small task for the local db elves? I hesitate turning some machines from my "farm" against them because I think I'll hit my db limits.

warachwe · 2020-11-15, 21:16

I notice that most of the new number is of the form a^n+-1 for 10001<=a<=20000 and n somewhere around 20. Most of these numbers already factored at cownoise.com . Is there anyway to just transfered them over?

EdH · 2020-11-15, 21:31

Quote:

Originally Posted by warachwe

I notice that most of the new number is of the form a^n+-1 for 10001<=a<=20000 and n somewhere around 20. Most of these numbers already factored at cownoise.com . Is there anyway to just transfered them over?

I think a script to transfer them would hit the db limits, but one could be written. All it would need to do is submit the composite with its factors via the report routine. But, every one of the new factors would create a new ID which would bump the limit after a short while.

unconnected · 2020-11-16, 16:42

A bunch of new small composites just arrived

I wonder what is the purpose of adding them to FDB - hoping the elves will factor them?

2020-11-02, 19:28	#12
EdH "Ed Hall" Dec 2009 Adirondack Mtns 3635₁₀ Posts	Resurrecting this thread. . . I'm going to bring this thread back to life to address the ongoing (elves) work for the db. I referenced in an aliquot thread my current work with small fdb composites and I'd like to move that discussion to this thread. If Chris2be8 is agreeable I may move our relevant posts from there to here later on. Currently I am running a couple Colab instances at 91 dd, but they are under-performing. Evaluating the backlog for even the 7x digit composites, I'm thinking of lowering my work down into that area. I'm using a pretty large random, so my duplication rate will hopefully be minimal. If anyone would like me to move higher and leave some "smaller fruit," don't be shy letting me know. I could easily work at 8x dd or higher, but I'm running ECM with some RPi's and a couple of my Colab sessions; one with YAFU and the other using the GPU branch of GMP-ECM and Msieve.

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-03, 19:12	#13
EdH "Ed Hall" Dec 2009 Adirondack Mtns 5·727 Posts	Base 162 table should be all "greened up" now. I've started "touching" all the sequences for the tables and it took a couple hours to do five tables this morning. I have started a script to run all of the tables except 220 and 284, since they're just being initialized and probably won't need any "help." I'm curious how long the script will actually take to get through everything.

2020-11-04, 13:53	#14
EdH "Ed Hall" Dec 2009 Adirondack Mtns 5·727 Posts	I was greeted this morning with the finished script, so every sequence in the current tables and base 72, has been accessed. Hopefully, that will get the update time back near normal.

2020-11-04, 14:22	#15
richs "Rich" Aug 2002 Benicia, California 2273₈ Posts	I have had one core of an i3 running the perl script utilizing yafu for the past 6 months or so. It is set to start at C81 and to choose one of the first 1,000 composites, so I have not had much problem with worker collisions.

2020-11-04, 16:56	#17
chris2be8 Sep 2009 5×401 Posts	@EdH, you are welcome to move my last 2 posts from the aliquot thread here, I was only using it as a place to let off steam about the amount of junk being added to factordb. I've got one system working from 70-79 digits, it grabs the smallest number in that range, factors it and repeats. So if you want to work in that range taking an offset of 10+rand(1000) would make absolutely sure you would not collide with me. I'm also working on 80+ digit numbers that can be factored by SNFS. I'm currently working around 84 digits (I was at 90 digits until recently). These are spaced out enough to make collisions unlikely. And thanks for the help. Chris

2020-11-15, 19:41	#19
EdH "Ed Hall" Dec 2009 Adirondack Mtns 5·727 Posts	>40,000 composites added to the <70 queue? @Chris: Do I remember you helping out the db when it gets this type of flooding? Should I turn a Colab session against them? Or, will this be a small task for the local db elves? I hesitate turning some machines from my "farm" against them because I think I'll hit my db limits.

2020-11-15, 21:16	#20
warachwe Aug 2020 2×5 Posts	I notice that most of the new number is of the form a^n+-1 for 10001<=a<=20000 and n somewhere around 20. Most of these numbers already factored at cownoise.com . Is there anyway to just transfered them over?

2020-11-16, 16:42	#22
unconnected May 2009 Russia, Moscow 9EA₁₆ Posts	A bunch of new small composites just arrived I wonder what is the purpose of adding them to FDB - hoping the elves will factor them?