Subproject #4: 10k-50k sequences to 110 digits - Page 23

firejuggler · 2010-05-26, 10:53

i have found the 5 following terms of my sequence and subminetted them to the factorDB. i think i got that right (although my 'credits' didn't move, need to be checked?). after that, for the 846 th term, i assigned myself an ECM here how do I 'do' this assignement?
sorry to bother you with those question, i'm a noob in that field

10metreh · 2010-05-26, 10:58

Ignore the "ECM work". Other than "Quick ECM", it doesn't work. (Don't ask why - it's complicated.) The database isn't for doing work, it's for storing results. Aliqueit should be used for doing work. Have you installed it and the programs it uses for factorization (GMP-ECM, YAFU, msieve, GGNFS)?

firejuggler · 2010-05-26, 11:04

yup, i have installed all the software, and its running... not as fast as i hoped for but still good

10metreh · 2010-05-26, 11:39

Forgot to mention this, but the credits don't work either. The DB is currently just a DB except for "Quick ECM".

smh · 2010-05-26, 12:19

Done with 36512

reserving 40500

firejuggler · 2010-05-26, 13:45

ok... factordb is acting strange... for 36684, at the 870 iteration there is a small problem...
4468722781...<102> = 2 · 53 · 57 · 1093 · 70843169 · 49685824598826035240380565051<29> · 19224367016503764005279927748469360887002331412508236569883<59>
even if i put 2*3*19*53*1093....etc it come back as 2*53*57... and even if i try to do a quick ecm with 57, it does not work. what should I do?

(and trying to repair 57 does not work)

Mini-Geek · 2010-05-26, 14:06

Quote:

Originally Posted by firejuggler

ok... factordb is acting strange... for 36684, at the 870 iteration there is a small problem...
4468722781...<102> = 2 · 53 · 57 · 1093 · 70843169 · 49685824598826035240380565051<29> · 19224367016503764005279927748469360887002331412508236569883<59>
even if i put 2*3*19*53*1093....etc it come back as 2*53*57... and even if i try to do a quick ecm with 57, it does not work. what should I do?

This is a known bug. A few numbers, such as 57, (3*19) are marked like they're composites with no known factors when they're really (often trivially, as in this case) fully factored. Since the DB thinks not all numbers in the line are fully factored, it doesn't let the sequence continue.

I suggest you ignore the DB for now, keep running the sequence locally, and when you're done with it post the .elf to the forum. A .elf file contains the factorizations of an aliquot sequence's numbers in plain text. It should be in aliqueit's folder and named alq_36684.elf.

Or if that sounds like too much trouble, you can just unreserve it and pick a new sequence to run. I'll put it back in the list of available sequences and someone else will do it.

firejuggler · 2010-05-26, 14:08

I am at c104, i'll get it to 110 before releasing it, with the elf file

EdH · 2010-05-26, 15:06

Correct me if I'm wrong, Mini-Geek, but doesn't submitting the full elf to the db via aliqueit, or submitting the correct lines manually, store the correct factored lines within the db? Then, when the 57, 159, etc. bugs are eradicated, the stored info will populate the db's sequences properly.

In this specific case, 512539091200423605342377877270021978828257857114084791961422307443426141684267634625913356380869010638 is the composite for iteration 871** of 36684 and the db has the next several lines up through a c105. So, firejuggler's input is apparently in the db, just not visible from the base 36684, until the 57 bug is chased away.

If the above is correct, there should be no need to post elfs, unless there is a reason for complete elfs elsewhere. Yes/No?

Additional thought: Someone who is taking a "buggy" sequence, should probably check their first new iteration against the db, to make sure it hasn't been added and is just not showing up due to the bug.

** iteration number fixed based on subsequent post by firejuggler

firejuggler · 2010-05-26, 15:40

Quote:

Originally Posted by EdH

<snip>
In this specific case, 512539091200423605342377877270021978828257857114084791961422307443426141684267634625913356380869010638 is the composite for iteration 571 of 36684 and the db has the next several lines up through a c105. So, firejuggler's input is apparently in the db, just not visible from the base 36684, until the 57 bug is chased away.

</snip>

hm, iteration 871, for the sake of accuracy

EdH · 2010-05-26, 15:59

Quote:

Originally Posted by firejuggler

hm, iteration 871, for the sake of accuracy

Indeed! Thanks! I must have had "57" stuck in my head. Oh, No! Perhaps I've contracted the bug from the db.

I was still able to edit the previous post, so I have done so, but added a note. . .

2010-05-26, 10:53	#243
firejuggler Apr 2010 Over the rainbow 2606₁₀ Posts	i have found the 5 following terms of my sequence and subminetted them to the factorDB. i think i got that right (although my 'credits' didn't move, need to be checked?). after that, for the 846 th term, i assigned myself an ECM here how do I 'do' this assignement? sorry to bother you with those question, i'm a noob in that field Last fiddled with by firejuggler on 2010-05-26 at 10:58

2010-05-26, 10:58	#244
10metreh Nov 2008 2×3³×43 Posts	Ignore the "ECM work". Other than "Quick ECM", it doesn't work. (Don't ask why - it's complicated.) The database isn't for doing work, it's for storing results. Aliqueit should be used for doing work. Have you installed it and the programs it uses for factorization (GMP-ECM, YAFU, msieve, GGNFS)? Last fiddled with by 10metreh on 2010-05-26 at 10:58

2010-05-26, 12:19	#247
smh "Sander" Oct 2002 52.345322,5.52471 29×41 Posts	Done with 36512 reserving 40500 Last fiddled with by smh on 2010-05-26 at 12:19

2010-05-26, 13:45	#248
firejuggler Apr 2010 Over the rainbow 2×1,303 Posts	ok... factordb is acting strange... for 36684, at the 870 iteration there is a small problem... 4468722781...<102> = 2 · 53 · 57 · 1093 · 70843169 · 49685824598826035240380565051<29> · 19224367016503764005279927748469360887002331412508236569883<59> even if i put 2319531093....etc it come back as 25357... and even if i try to do a quick ecm with 57, it does not work. what should I do? (and trying to repair 57 does not work) Last fiddled with by firejuggler on 2010-05-26 at 14:04

2010-05-26, 14:08	#250
firejuggler Apr 2010 Over the rainbow 5056₈ Posts	I am at c104, i'll get it to 110 before releasing it, with the elf file Last fiddled with by firejuggler on 2010-05-26 at 14:10

2010-05-26, 11:04	#245
firejuggler Apr 2010 Over the rainbow 2·1,303 Posts	yup, i have installed all the software, and its running... not as fast as i hoped for but still good

2010-05-26, 11:39	#246
10metreh Nov 2008 4422₈ Posts	Forgot to mention this, but the credits don't work either. The DB is currently just a DB except for "Quick ECM".

2010-05-26, 15:06	#251
EdH "Ed Hall" Dec 2009 Adirondack Mtns 7376₈ Posts	Correct me if I'm wrong, Mini-Geek, but doesn't submitting the full elf to the db via aliqueit, or submitting the correct lines manually, store the correct factored lines within the db? Then, when the 57, 159, etc. bugs are eradicated, the stored info will populate the db's sequences properly. In this specific case, 512539091200423605342377877270021978828257857114084791961422307443426141684267634625913356380869010638 is the composite for iteration 871 of 36684 and the db has the next several lines up through a c105. So, firejuggler's input is apparently in the db, just not visible from the base 36684, until the 57 bug is chased away. If the above is correct, there should be no need to post elfs, unless there is a reason for complete elfs elsewhere. Yes/No? Additional thought: Someone who is taking a "buggy" sequence, should probably check their first new iteration against the db, to make sure it hasn't been added and is just not showing up due to the bug. iteration number fixed based on subsequent post by firejuggler Last fiddled with by EdH on 2010-05-26 at 15:59 Reason: even better accuracy and additional thought

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Subproject #9: 150k-200k sequences to 110 digits	Mini-Geek	Aliquot Sequences	151	2011-05-14 09:01
Subproject #6: 50k-100k sequences to 110 digits	10metreh	Aliquot Sequences	203	2010-11-14 15:00
Subproject #5: 800k-900k sequences to 100 digits	10metreh	Aliquot Sequences	431	2010-05-18 02:21
Subproject #2: 500k-600k sequences to 100 digits	10metreh	Aliquot Sequences	690	2009-10-14 09:02
Subproject #1: 210k-250k sequences to 100 digits	henryzz	Aliquot Sequences	204	2009-07-30 12:06