Cleaning out the list
 

Taking 31080, 31240, 31446, 31560, 31710, 31890

Leaving 30024: 111 digits, 2*3^2*sieve-ready C110
Leaving 30100: 115 digits, 2^2*7*47*sieve-ready C112

Leaving 30450: iteration 677, 125 digits, 2^5*3*7 lead terms, ECM'd C120

33000: i1542, size 113, [COLOR=Red]2*3^3*5[/COLOR]

Leaving 31446: iteration 1591, 123 digits, 2^3*3^4, ECM'd C115 cofactor

done with 28008
reserving 35058

leaving 31080: i785, 122 digits, 2^4*31*ECM'd C119

leaving 30352: i1641, 116 digits, 2^2*3*5*ECM'd C114
leaving 31890: i897, 117 digits, 2^2*7, cofactor ECM'd C111

Leaving 30420: i1075, 112 digits, 2*3*ECM'd C112

leaving 31560: i2645, 118 digits, lead term 2^3*3^2, ECM'd C112 cofactor
leaving 31710: i2001, 122 digits, lead term 2^2*3^2*7, ECM'd C112 cofactor

34308 acquired downdriver at 122 digits (i927), but at this size it takes quite a while even to follow a downdriver.

Reserving 39690 and 39870.

31240 done: i943, 114 digits, 2*3*7*ECM'd C113

Keeping 32280 at 122 digits - has the downguide.
Done with 32496, 111 Digits, 2^2*7
Done with 32796, 114 Digits, 2^2*7

Reserving:
39012, 39060, 39270, 39282, 39576, 39648, 39672, 39798, 39840, 39990

39870: i4386, size 111, [COLOR=Red]2*3^4[/COLOR]

33312: i1006, size 111, [COLOR=Red]2^2*3*7[/COLOR]

done with 35058
reserving 35196

39690: i345, size 111, [COLOR=Red]2^3*3*5[/COLOR]
Taking 37128 and 38112.

37128: i809, size 111, [COLOR=Red]2^3*3*5[/COLOR]

Taking 36468 and 37968.

Keeping 39012, 122 digits, 2^4*7. Has lost both 2*3 and 2^5*3*7 on its way up.

done with 35196
reserving 35328

36468: i1339, size 113, [COLOR=Red]2^4*3*5^3*29*31[/COLOR]

37968: i2365, size 111, [COLOR=Red]2^2*3^2*7[/COLOR]

Reserving 37632.

37632: i2079, size 112, [COLOR=Red]2^2*7[/COLOR]

Keeping 39060 as well. It is to 127 digits, with 2^5*3^5*5 guide

Reserving 37332, 37620

I'll release 37332

And reserve 35442

I'll also release 37620

and take 35856

Done with 39282, 115 Digits, 2*3*5

38112: i939, size 121, [COLOR=Red]2^3*3*5*7
[COLOR=Black]Reserving 36108.[/COLOR]
[/COLOR]

done with 35328
reserving 35720

36108: i1305, size 110, [COLOR=Red]2^2*7[/COLOR]
Taking 36984 and 38280.

34308 acquired the downdriver again at index 1461, 128 digits. This ride is taking quite a long time, it's been 107 or more digits for over 600 steps and I've done more than 40 GNFS jobs of more than 100 digits to get here.

(last downdriver for five steps 1315-1319, before that 1117-1146, before that 928-985. Hope this one's more durable)

Done with 39270, 112 Digits, 2^6*5^4*7*127
Done with 39576, 123 Digits, 2^2*7

Reserving 36552.

Releasing 35856 and 35442

Reserving 36348 and 36390

Releasing 36348

Reserving 38760

36552: i1558, size 113, [COLOR=Red]2^2*7[/COLOR]
I accidently ran 38760, so it is now on 109 digits.

[QUOTE=unconnected;215296]
I accidently ran 38760, so it is now on 109 digits.[/QUOTE]
You can continue 38760, I'll take 38664 instead

Releasing 36390

Reserving 38196

Done with 39648, 120 digits, 2^2*3*7

Done with 38196 and 38664

reserving 36792 and 36512

38760: i1156, size 110, [COLOR=Red]2^2*7[/COLOR]

38280: i1643, size 112, [COLOR=Red]2^2*3*7
[COLOR=Black]Reserving 36420.[/COLOR]
[/COLOR]

done with 35720
reserving 36504

reserving 36684

[QUOTE=firejuggler;216090]reserving 36684[/QUOTE]

Welcome to the project! :smile:

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 [URL="http://factordb.com/search.php?id=165916830&adv165916830=%3E+%3E"]here[/URL] how do I 'do' this assignement?
sorry to bother you with those question, i'm a noob in that field

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)?

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

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

Done with 36512

reserving 40500

ok... factordb is acting strange... for 36684, at the 870 iteration there is a small problem...
[URL="http://factordb.com/search.php?id=165919062"][COLOR=#002099]4468722781...[/COLOR][/URL]<102> = [URL="http://factordb.com/search.php?id=16882"][COLOR=#000000]2[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=107"][COLOR=#000000]53[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=10144"][COLOR=#002099]57[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=788"][COLOR=#000000]1093[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=165919063"][COLOR=#550000]70843169[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=165919065"][COLOR=#550000]49685824598826035240380565051[/COLOR][/URL]<29> · [URL="http://factordb.com/search.php?id=165919066"][COLOR=#550000]19224367016503764005279927748469360887002331412508236569883[/COLOR][/URL]<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)

[quote=firejuggler;216207]ok... factordb is acting strange... for 36684, at the 870 iteration there is a small problem...
[URL="http://factordb.com/search.php?id=165919062"][COLOR=#002099]4468722781...[/COLOR][/URL]<102> = [URL="http://factordb.com/search.php?id=16882"][COLOR=#000000]2[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=107"][COLOR=#000000]53[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=10144"][COLOR=#002099]57[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=788"][COLOR=#000000]1093[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=165919063"][COLOR=#550000]70843169[/COLOR][/URL] · [URL="http://factordb.com/search.php?id=165919065"][COLOR=#550000]49685824598826035240380565051[/COLOR][/URL]<29> · [URL="http://factordb.com/search.php?id=165919066"][COLOR=#550000]19224367016503764005279927748469360887002331412508236569883[/COLOR][/URL]<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?[/quote]
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.

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

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

[quote=EdH;216215]
<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>
[/quote]
hm, iteration 871, for the sake of accuracy

[quote=firejuggler;216222]hm, iteration 871, for the sake of accuracy[/quote]
Indeed! Thanks! I must have had "57" stuck in my head. Oh, No! Perhaps I've contracted the bug from the db.:sad:

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

36420: i1097, size 110, [COLOR=Red]2^4*31[/COLOR]
36984: i2662, size 115, [COLOR=Red]2^2*7[/COLOR]
Reserving 40836 41364 41784 42672 42942 43000

[quote=EdH;216215]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.[/quote]
Yep, that's so.
[quote=EdH;216215]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?[/quote]
Yes, I suppose you're right. But it's not what we've been doing lately, and I didn't want to throw too many complications at firejuggler, considering he's new here. :smile:
[quote=EdH;216215]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.[/quote]
Yes, quite true. If it looks like there's a need for it, a notice saying so could be added to the first post here, but I don't think very many sequences are bugged (and also worked past that bug), so it might be more trouble than it's worth. Plus Syd has been around more lately and I just posted in his thread again, so hopefully this will be fixed soon and be all behind us.

groumph... 36684 : 928 hit me hard today ([URL="http://factordb.com/search.php?se=1&aq=512539091200423605342377877270021978828257857114084791961422307443426141684267634625913356380869010638&action=last20"] here[/URL], 36684 broken at 870, cause of 57); I had to manually take care of it as aliqueit didn't... anyway... p50 and p54 factors... took 3.09 hours
[code]
Number: example
N = 6671070323497881696403979895082072399614158451917545681942017208119134701880063579999656049450688484271 (103 digits)
Divisors found:
r1=58767016187377007874915025699882460094567363784937 (pp50)
r2=113517254342595142750021507529216219123186779929018583 (pp54)
Version: Msieve v. 1.45
Total time: 3.09 hours.
Factorization parameters were as follows:
n: 6671070323497881696403979895082072399614158451917545681942017208119134701880063579999656049450688484271
Y0: -129949133012079298566
Y1: 36608229247
c0: 16476014775931209438069815
c1: 1913276381475814562559
c2: -286655913100194197
c3: -425983891959
c4: 82515402
c5: 180
skew: 54719.10
type: gnfs
Factor base limits: 2300000/2300000
Large primes per side: 3
Large prime bits: 26/26
Sieved algebraic special-q in [0, 0)
Total raw relations: 4591789
Relations: 444786 relations
Pruned matrix : 256945 x 257173
Polynomial selection time: 0.37 hours.
Total sieving time: 2.46 hours.
Total relation processing time: 0.04 hours.
Matrix solve time: 0.13 hours.
time per square root: 0.08 hours.
Prototype def-par.txt line would be: gnfs,102,5,59,2000,0.0009,0.35,200,15,15000,2000,2300000,2300000,26,26,49,49,2.6,2.6,100000
total time: 3.09 hours.
x86 Family 6 Model 23 Stepping 6, GenuineIntel
Windows-XP-5.1.2600-SP3
processors: 2, speed: 2.83GHz
[/code]
driver= 2*3*5*7...
it will never let it go down...

[QUOTE=firejuggler;216364]I had to manually take care of it as aliqueit didn't[/QUOTE]

What was the error? Are you using factmsieve.py or factMsieve.pl?

reserving 40092

Releasing 36792

reserving 40722

Done with 39672, 117 digits, 2^2*7
Done with 39798, 110 digits, 2^2*3*7^2
Done with 39840, 113 digits, 2^3*3*5*7

Done with 42672, 42942, 43000.

done with 36684 110 digits, driver 2*3*23 there is no escape..
taking 44712

aaaand done with 44712 2^3*3, taking 43980

Done with 40836 and 41364.
Reserving 43506 and 43974.

done with 43980, 111 digits, 2^6*3 driver

taking 40872

41784: i889, size 111, [COLOR=Red]2^5*3*7[/COLOR]

Releasing 40500 and 40722

Reserving 40518, 40866

Unreserving 40096 at i=2421, size 116, [COLOR="Red"]2^3*3[/COLOR]. (the driver had changed from [COLOR="Red"]2^4*3*31[/COLOR] directly to [COLOR="Red"]2^3*3[/COLOR] in line 2373.)

[B]Reserving 40224.[/B]

done with 40872, 2^6*5 driver
taking 42312

[QUOTE=firejuggler;216981]done with 40872, 2^6*5 driver[/QUOTE]

Actually it's 2^6*127, which is a very nasty driver.

871 say 2^6*5*127... i suppose you ommit 5 cause 2^6>5?
or because 870 is 2^6*127...
(sorry for all the question i'm still learning)
and now 2^6*5^2*127 for 875
(at the time of first post was finishing 871)

[QUOTE=firejuggler;216997]871 say 2^6*5*127... i suppose you ommit 5 cause 2^6>5?
or because 870 is 2^6*127...
(sorry for all the question i'm still learning)
and now 2^6*5^2*127 for 875
(at the time of first post was finishing 871)[/QUOTE]

The driver isn't always just the smallest factors, especially when dealing with 2^6*127. The driver in these cases is still 2^6*127, even though it also has a 5^2 factor. The 5^2 factor isn't part of the driver, it just makes the sequence grow quicker as long as it's in there.
A list of drivers is at:
[url]http://mersennewiki.org/index.php/Aliquot_Sequences[/url]

so, not only does it have a 'perfect' driver (the worst of them), but the 5^2 make it even worse?

[QUOTE=firejuggler;217006]so, not only does it have a 'perfect' driver (the worst of them), but the 5^2 make it even worse?[/QUOTE]

Yep. Fortunately, since it's not part of the driver, the 5^2 is unstable (i.e. it's likely to go away at any time).

done with 36504
reserving 41160

done with 42312.
taking 41610

done with 41610 driver 2*3 as 2*3^3 is considered instable, right?
taking 43332

[QUOTE=firejuggler;217492]done with 41610 driver 2*3 as 2*3^3 is considered instable, right?[/QUOTE]

Yep. :smile:

done 43332 2^4*31
taking 42532

done with 40866

Reserving 41328

Reserving 44160

Releasing 41328

releasing 40518

reserving 43578

done with 42532, 2^4*31 driver
taking 41982

done with 39990, 114 digits, 2^2*3^2*7

Reserving
43158, 43456, 43752, 43758,

Unreserving 40224 at index 2483, size 113, [COLOR="Red"]2*3[/COLOR]*<small factors>*c82 (with little ECM on the c82)

41982 : 1718 has a 3*19 factor (57 is still considered composite)
following line is
3382153428399072538847573742821380566489993749198821606892113307360201528260648170388959018172518183906152274
(c109)

Could you please run this to 110 digits anyway?

[QUOTE=Andi47;218140]Unreserving 40224 at index 2483, size 113, [COLOR="Red"]2*3[/COLOR]*<small factors>*c82 (with little ECM on the c82)[/QUOTE]

Extended to i2502: 114 digits with 2*3 and C101, ECM upto B1=50k complete with yafu

41982 ran to 110 digits
broken at 1718 cause of 3*19
[quote]
1719 . 3382153428399072538847573742821380566489993749198821606892113307360201528260648170388959018172518183906152274 = 2 * 3 * 103 * 235307 * 984397 * 50957807 * 150985867 * 494958570131 * 29536746246151 * 5748706603693543321393759 * 36538526574911668859346950717
[/quote]
taking 49950

Releasing 43578 and 44160

I'll run 90K - 100K to 110 digits over the next couple of weeks. It will run unattended so no promises on how far it will get.