Yes, it's just got to 130 digits for the second time

(updated in factordb)

Nice!

In the absence of the central sequence status repository, I've started my old "get last line" script; it only fetches ~420 sequences at a time and then factorDB throttles this IP for an hour; and then, the only downdriver I encountered (so far) was your 8154.

I have a [U]complete[/U] database with all the sequences, no more than 1 week old, if someone needs it (even when compressed, it is huge!).

Long version: I am trying to perfect my perl skill (i.e. on a scale from 1 to 10, I am trying to advance from 2 to 3, or from 3 to 4, hehe - I am a "C and assembler" programmer, I consider myself a very good one, but perl's logic sometime tries and succeeds to confuse me totally). So I did different scripts and combine them in different ways, to:
a) take all numbers from 1 to 1M and, if not prime, put them in a sorted list (there are totally 921500 sequences, including odd numbers, excluding primes). This list is saved and later reconstructed from the files in the root folder of the project, see below.
b) search the first element in the list, and if its size is less than 80 digits, call aliqueit to advance the sequence one digit (this will create 921500 ".elf" files on disk, most of them will stay on the "root folder" of the project, other will move around, see below)
c) if the size is larger, tries to factor it, but in the same time tries to get the rest of the sequence from the factorDB. Whatever succeeds first.
d) check for mergers (if sequence x merges with sequence y and x<y, a folder x_M is created and y.elf is moved there, sequence y is deleted from the list, and if y_M folder exists, it is moved there too).
e) checks for endings, if a prime ending detected, i.e. sequence s ends in prime p, the ".\Ended\Prime\p_E" is created, where p is the ending prime, and the sequence (and its associated s_M if exists) is moved there.
f) check for cycles, if a cycle is detected, then the smaller number m in the cycle is found, the ".\Ended\Cycle\m_C" is created, sequence s is moved there (with s_M folder, if it exists).

This task took about 20 days single core, except when a large factorization was needed (few elfs can not be downloaded from fDB or are broken!) and yafu was called (by aliqueit.exe, that is its normal behavior), during which activity, all 8 cores were used. Everything finished last week, letting the (about) nine thousand sequences in the root folder, which won't merge, and won't end. Yet.

The nice part of it is that if you use the DOS command "tree -all >>file" (in some OS'es it is "-f", to list the files in each folder), than you get a very nice aliquot tree (not available anywhere on the web, according with my knowledge) in a text file.

If Xyzzy give me some uploading space here, I can try to upload the tree, is not very big, about 20MB if uncompressed. Maybe we should have a mersenneforum/aliquots folder? as we have for mfakto and Misfit, etc.

The future plan is to make a database where you can navigate through this tree and see the sequences too. Right now, the "searching for a sequence" is going like: you open your favorite file manager, windows explorer, or total commander, etc, search for "123456.elf" file, and you find it in the root, or in some folder (assuming is not a prime), then you can open it with a text editor to look inside, or you can "navigate" upper side of the "path" (clicking the ".." folder if total commander is used, or the "crumble" path) to see the important mergers of the respective sequence (in case it is not in the project's root). The path to the file always tells you the important mergers of the sequence, in reversed order. For some paths I had to recombine (manually) the files, as the OS won't accept an infinite-long path.

Whatever...

But making a database will take time (still [STRIKE]thinking[/STRIKE] dreaming about the interface, i.e. trying to find a convenient graphical form to present the things).

[STRIKE]Why don't I take 569448 for a ride...[/STRIKE]

Hmm. It's not noted in the first post but it seems to be reserved by Dmitry. Ok

[QUOTE=unconnected;379198]Taking 569448, 968922 and 528318.[/QUOTE]

[QUOTE=Batalov;383214][STRIKE]Why don't I take 569448 for a ride...[/STRIKE]

Hmm. It's not noted in the first post but it seems to be reserved by Dmitry. Ok[/QUOTE]
It should be in the first post. I am not sure how I missed this. Does anyone know of any other sequence reservations I have missed?

I need to go out now but I will sort this out later.

I'll run 725490 and 109944 for a while.
And 169698.

With the return of the reservations page, I would like to reserve all numbers last touched in 2013 and with 118 or fewer digits. I think there are 232 of them. I will run them until they hit a 120-or-more-digit cofactor; I appreciate this will take some time.

Reserving 101142 173904 261360 299424 337518 414750 454848 526560 582750 617520 680586 724626 769656 805020 831588 861492 898320 959712
Reserving 112350 176340 261816 302992 341712 41610 460374 531492 583680 620328 682080 727812 771060 814890 832216 865650 898488 960564
Reserving 120588 187752 263424 305460 342132 41982 468018 533538 585090 623334 683982 728610 771720 816564 834264 86760 907056 962982
121128 187880 271908 307740 352080 421428 482196 535980 588330 633090 694188 729960 771764 817662 834762 871038 908904 966654
131880 209976 27978 308232 357000 422904 484500 537450 589520 640362 699768 730536 771870 817992 836264 87612 909020 971424
135294 218808 279816 312150 375480 426126 502950 550578 590376 641910 701760 730680 775908 818856 837198 877476 918072 971784
135612 22518 282600 312330 380520 426972 503220 553152 591264 64596 70464 732360 776616 821640 840258 883820 921240 973812
144894 228504 288680 314188 394440 433068 503280 557440 594648 645996 706200 735096 779868 822216 840294 886040 929052 974766
150648 241860 289840 321246 395850 433290 505230 568104 601104 652302 708744 743106 78474 822852 84564 887760 934836 975738
152640 247440 290836 321672 401508 437736 508400 56910 603342 652680 711354 74760 785556 823176 84840 893760 941934 984654
161820 25380 292308 322686 411744 438976 516642 575430 60452 672294 713034 754992 791124 823608 853552 896310 943410 993000
162990 254010 295452 327852 41328 444372 522690 577170 607386 673716 71688 763168 796260 827778 858704 896448 949746
168372 257928 296886 328770 413976 454380 523920 580692 610944 67608 721364 768042 800130 828798 859656 898224 950808

There isn't room in the first post for all of fivemack's reservation. I have put 48 in already using the new automated script and it thinks I have room for another 59. There isn't room for the remaining 184. We have 212 currently.

I would just modify the template in the script noting the reservation and linking to the post. I've encountered similar issues in the past. Were there any issues with the script?

I am open to any scheme for parsing (un)reservations from the thread that you can agree to.

I'll Add 264456, take it for a spin

Reserving 480522 (got a p50 while ecm'ing dangling cofactors in a few free sequences; could be a sign from above)

Dropping 480522 (c131, 2^3 * 3)
Reserving 458514

Reserving 706104

(it's broken in the factordb; iteration 938 should be 41056247340555352160404327938385124070914568373289825909365899066462655085280970624745514385381813768355098498287234724 ; it's now at iteration 952 )

Reserving 143850

Reserving 51282.

Reserving 660212

Dropping 264456 with 2^2*3*7, t30 on cofactor;

[strike]adding 140832[/strike] looks like someone's been working on that;

Reserving 532440

Dropping 528318

Reserving 971696

Reserving 389232.

Reserving 624162

Dropping 532440 at 130 digits with 2^4*3^5

Adding 435504

Dropping 435504 at 130 digits with 2^6 * 3 * 127

Reserving 888692

Dropping 971696

Reserving 865164

[QUOTE=Sergiosi;384026]Dropping 971696

Reserving 865164[/QUOTE]

Ups, sorry, my computer extended this sequence a bit during the weekend. To let you know, I put all the lines to the database and stooped all works on it.

@Drdmitry: No problem :smile:

But unfortunately someone else is still extending the sequence. :mad:

It looks as if there is some relatively serious compute power working on the sequences without regard to reservations; several of the sequences I've been running for years have been extended by hundreds of steps in the last few days.

Admittedly I have about half an Avoton core working on them at the moment, but it appears there may be an automatic plucker of low-hanging fruit around and it might be better to work higher up the branches.

What size are the composites involved? Could they be being done by [EMAIL="yafu@home"]yafu@home[/EMAIL]?

Reserving 964680, 140832, 853740, 137106.

[QUOTE=unconnected;384159]Taking 964680, 140832, 853740, 137106.[/QUOTE]

Could you please use a word beginning with R or A for reserving and U or D for dropping. Taking doesn't register on the script.

[QUOTE=henryzz;384163]Could you please use a word beginning with R or A for reserving and U or D for dropping. Taking doesn't register on the script.[/QUOTE]

Ok, no problem.

Dropping 109944, 169698, 458514, 725490, 660212 (terminated)

Taking 56784

Thanks to changes by Dubslow Taking now works with the script.

Dropping 865164

Reserving 985950

Dropping 888692 at size 126 with 2^6*127

Adding 680526

Reserving 793968

Reserving 872760, 808230, 28182.

Dropping 56784 (lost 2^6*127, acquired 2^4*31)

Taking 49600, 55938, 86712, 89448

Dropping 680526 at sz 130 with no driver but a pesky 3

Adding 240792

Bother this for a game of soldiers
 

There is some kind of procedure out there which is moving sequences on whether they're reserved or not. So I'd like to drop my whole reservation of medium-sized sequences from 2013, because they're clearly being run anyway.

There may still be scope to run sequences which are at C120 or larger, but at present the conservative assumption is that, if you ever put something in the database with an end term less than C120, it will be run away with.

It's not worth being cross abut this, but it's really quite a discouragement.

Dropping 101142 173904 261360 299424 337518 414750 454848 526560 582750 617520 680586 724626 769656 805020 831588 861492 898320 959712
Dropping 112350 176340 261816 302992 341712 41610 460374 531492 583680 620328 682080 727812 771060 814890 832216 865650 898488 960564
Dropping 120588 187752 263424 305460 342132 41982 468018 533538 585090 623334 683982 728610 771720 816564 834264 86760 907056 962982
Dropping 121128 187880 271908 307740 352080 421428 482196 535980 588330 633090 694188 729960 771764 817662 834762 871038 908904 966654
Dropping 131880 209976 27978 308232 357000 422904 484500 537450 589520 640362 699768 730536 771870 817992 836264 87612 909020 971424
Dropping 135294 218808 279816 312150 375480 426126 502950 550578 590376 641910 701760 730680 775908 818856 837198 877476 918072 971784
Dropping 135612 22518 282600 312330 380520 426972 503220 553152 591264 64596 70464 732360 776616 821640 840258 883820 921240 973812
Dropping 144894 228504 288680 314188 394440 433068 503280 557440 594648 645996 706200 735096 779868 822216 840294 886040 929052 974766
Dropping 150648 241860 289840 321246 395850 433290 505230 568104 601104 652302 708744 743106 78474 822852 84564 887760 934836 975738
Dropping 152640 247440 290836 321672 401508 437736 508400 56910 603342 652680 711354 74760 785556 823176 84840 893760 941934 984654
Dropping 161820 25380 292308 322686 411744 438976 516642 575430 60452 672294 713034 754992 791124 823608 853552 896310 943410 993000
Dropping 162990 254010 295452 327852 41328 444372 522690 577170 607386 673716 71688 763168 796260 827778 858704 896448 949746
Dropping 168372 257928 296886 328770 413976 454380 523920 580692 610944 67608 721364 768042 800130 828798 859656 898224 950808

Now, if these ones get sniped, I will be quite vexed
 

Reserving 236448 347814 407058 597450

[QUOTE=Dubslow;384366]Adding 240792[/QUOTE]

In a lucky turn of events, this caught the downdriver literally 3 lines after its current state when I reserved it...

I moved few of the lower sequences since I made my database, but negligible, I am not the one who is pushing "everything". There are much bigger guns out there, most probably the "elves" of the DB itself, or maybe yoyo-script runners.

OTOH, there is (again) a problem with the pagination of the current forum thread, which happens every time when posts are deleted from the reservation thread. I see 48 pages but can't access them, the click on 48 sends me on 47.

[QUOTE=fivemack;384399]There is some kind of procedure out there which is moving sequences on whether they're reserved or not. [/QUOTE]
Just in case, reporting: it's not me, either.

Taking 172692.

Reserving 20520 88956

Dropping 240792 sz 125 2^5*3*7

Taking 78816

Reserving 359250 and 238836.

Dropping 578550

Dropping 359250, 172692, 140832, 853740, 137106, 51282, 968922.

Reserving 230916 at i1696.

Reserving 21930, 32796, 95136, 215748, 408810

Dropping 55938, 86712

Repeating a slightly tedious warning
 

Do not put sequences with cofactors less than C116 into the database, even with reservations, since some kind of worker thread will pick them up and keep running them.

Dropping 347814 (C125 is ECMed)

Drop 28182, 238836, 389232, 808230, 872760, 964680.

BTW, nice [URL="http://factordb.com/sequences.php?se=1&aq=872760&action=range&fr=4892&to=4896"]escape[/URL] from tough driver.

[QUOTE=unconnected;385751]Drop 28182, 238836, 389232, 808230, 872760, 964680.

BTW, nice [URL="http://factordb.com/sequences.php?se=1&aq=872760&action=range&fr=4892&to=4896"]escape[/URL] from tough driver.[/QUOTE]:bow: Nice! I keep an eye out for the full 2^9 driver, but not often enough, obviously.

Check out the graph on [URL="http://factordb.com/sequences.php?se=1&aq=7044&action=last20&fr=0&to=100"]7044[/URL]!

Dropping 154548

Taking 135612.

Taking 209760

Taking 718152

Taking 279816.

Dropping 407058 283872 88956 597450

Someone has shot three of my foxes, though 597450 died of its own accord

Taking 823176.

Dropping 78816

Taking 299334 468720

[QUOTE=unconnected;385850]Taking 279816.[/QUOTE]

Sorry, I've been running that one since 18 October; I've uploaded my work.

Dropping 823176 (Currently C95, 2^2*3*5*7 are small factors.)

Taking 768612 893352

Taking 428928 and 914788.

[QUOTE=fivemack;385510]Do not put sequences with cofactors less than C116 into the database, even with reservations, since some kind of worker thread will pick them up and keep running them.[/QUOTE]
I have run several tests (including leaving a couple of baits - the downdrivers - in the open) and none of my sequences were moved.

ymmv, of course.

Taking 113960

Taking 72492, 112968, 120760, 125016, 167358, 173808, 181980, 198696

My downdriver on 230916 was stolen today. It made it all the way down to 8 digits at i2932. I made the mistake of leaving the downdriver in the open when I left for work this morning....

That being said, how does one check to see if a merge has occurred?

[QUOTE=richs;386986]My downdriver on 230916 was stolen today. It made it all the way down to 8 digits at i2932. I made the mistake of leaving the downdriver in the open when I left for work this morning....

That being said, how does one check to see if a merge has occurred?[/QUOTE]If it merged coming back up, it would leap from where you finished off up to whereever the merged/merging sequence was. I'll make a quick check and see if I can tell......BRB!

If it would have merged, it wouldn't be at 113 digits in fdb. There is no other sequence at 113 digits.

[QUOTE=LaurV;386990]If it would have merged, it wouldn't be at 113 digits in fdb. There is no other sequence at 113 digits.[/QUOTE][Assuming, of course, that the status page was completely up to date.] But you are correct, there was no merge. Really disappointing, it was down at 8 digits for more than just a few steps....[code] 2923 . 194619554 = 2 * 97309777
2924 . 97309780 = 2^2 * 5 * 23 * 211543
2925 . 115926572 = 2^2 * 29 * 911 * 1097
2926 . 94362388 = 2^2 * 31 * 283 * 2689
2927 . 76764652 = 2^2 * 2753 * 6971
2928 . 57641564 = 2^2 * 3559 * 4049
2929 . 43284436 = 2^2 * 13 * 23 * 36191
2930 . 41839148 = 2^2 * 13 * 271 * 2969
2931 . 37329172 = 2^2 * 53 * 176081
2932 . 29229824 = 2^8 * 13 * 8783
2933 . 33610912 = 2^5 * 23 * 45667
2934 . 35439104 = 2^9 * 19 * 3643
2935 . 39117136 = 2^4 * 17 * 143813
2936 . 41131076 = 2^2 * 7 * 1468967
2937 . 41131132 = 2^2 * 7 * 1468969
2938 . 41131188 = 2^2 * 3^2 * 7^3 * 3331
2939 . 80153612 = 2^2 * 7^3 * 11 * 47 * 113
2940 . 103705588 = 2^2 * 7 * 101 * 36671[/code]

[QUOTE=schickel;386994][Assuming, of course, that the status page was completely up to date.] [/QUOTE]
No need to look to any status page, just to the sequence in discussion on fdb. All of them were over a top, say 116 digits sometime in their past, and in (my, your, Dubslow's etc) database we don't have sequences at 113 digits. Even if the "tables" are not really actual, te sequence in discussion does not exhibit a top over 116 digits after the deep of 8 digits, so it can't be a merge. If it would merge with something, as you personally said, it will jump immediately from "where you left it" to the last top of that "something" (which is over 116 digits) and than (eventually) back at 113. Except if it (unfortunately) merged with a sequence which is "corrupted" in the DB. But that is not the case.

Just to be sure, I also have checked it against my db after I posted (which db is not updated since long time, i.e.since I was talking about it in september or so, but everything is over 115 digits) and didn't find anything.

[QUOTE=LaurV;386997]No need to look to any status page, just to the sequence in discussion on fdb. All of them were over a top, say 116 digits sometime in their past, and in (my, your, Dubslow's etc) database we don't have sequences at 113 digits. Even if the "tables" are not really actual, te sequence in discussion does not exhibit a top over 116 digits after the deep of 8 digits, so it can't be a merge. If it would merge with something, as you personally said, it will jump immediately from "where you left it" to the last top of that "something" (which is over 116 digits) and than (eventually) back at 113. Except if it (unfortunately) merged with a sequence which is "corrupted" in the DB. But that is not the case. [/quote]OK, I didn't know what the lowest sequence in the DB is currently, since I haven't taken an overall look at things lately, but knowing that is a quicker way. Good to remember. I guess a merge with a broken sequence should be obvious, too, so that's ruled out. Still too bad that that low a dip did not pau off....[quote]Just to be sure, I also have checked it against my db after I posted (which db is not updated since long time, i.e.since I was talking about it in september or so, but everything is over 115 digits) and didn't find anything.[/QUOTE]I remembered that you had said something about getting a current status on everything locally right after I hit submit, but did not go back and edit because I got busy. Sorry, next time I might remember sooner.

This also prompted me to start an update on my local status (and "all open sequences" backup). Scary, when I checked just now I see that I haven't pulled everything since May. Where did the time get to?

Thanks schickel for checking, and thanks Laurv for your explanation and checking.

The hijacking of that sequence continued overnight. With the size of the composites and how quickly it is being advanced, it's not due to Factor Database workers.

Having trouble with the script right now. It is timing out on line 37. I suspect it could have something to do with my updating Cygwin. I will hopefully get to fixing/manually updating soon. My new job is taking most of my energy currently.
Edit just realized I can't access allseq.txt on dubslow's site. edit2: or dubslow's site at all

My router shat itself this morning, and took all my port forwards with it... give me an hour or so.

[QUOTE=Dubslow;387048]My router shat itself this morning, ....[/QUOTE]
Lovely metaphor.

[QUOTE=Batalov;387053]Lovely metaphor.[/QUOTE]

Well that's about as apt a description as I cared to create. According to IRC/Mumble, around 4 am the internet died; when I woke up I tried to trouble shoot, but only got as far as "power cycling the router allows me to connect to it (e.g. view firmware) for ~10-30 seconds before all its lights turn on and stay on (even lights that shouldn't be), at which time my OS says the cable is disconnected".

After running for a few hours with the hardware switch in AP mode, I moved it back to Router mode which spontaneously started working, but with the config utterly gone.

So, I called it like I see it.

In a probaby-unrelated matter (though it very well could be), my ISP did something so that I'm no longer in their DMZ -- I'll fix that tomorrow.

Taking 815736.

Dropping 135612, 279816, 428928, 914788. Taking 783804, 807288.

As I still can't access Dubslow's page I have done a manual update.

Dropping 21930, 32796, 49600, 89448, 95136, 112968, 215748, 408810

Taking 991608.

Dropping 143850

(2^2*5*7*C138, ready for GNFS but really not a high priority)

Done another manual update.

Any progress with the page Dubslow?

Finally worked out the DMZ issues.

Additionally, [URL="https://github.com/dubslow/MersenneForumAliquot/commit/b89432ae6673b2b5ad4afc8dcc6bc94f8b8f7dfc"]here[/URL]'s a patch so that the script will work without needing to poll my site for info.

Dropping 43456 (2^2 * 7 * sufficiently-ECMed C137)

Dropping 991608, taking 812070.

Taking 31560 41760

Dropping 985950.

Taking 581574.

Dropping 994944.

Taking 912380.

Dropping 793968
Taking 308232

Just made the script slightly more robust in that it uses words rather than letters to decide whether to reserve or unreserved. This means that you can no use words such as reserve, release etc. without an issue. I will be monitoring it carefully to make sure I haven't forgotten words.
The code is now:
[code] if 'Unreserv' in line or 'unreserv' in line or 'Drop' in line or 'drop' in line or 'Releas' in line or 'releas' in line:
for s in re.findall(r'(?<![0-9])[0-9]{5,6}(?![0-9])', line):
drop.append(int(s))
elif 'Reserv' in line or 'reserv' in line or 'Add' in line or 'add' in line or 'Tak' in line or 'tak' in line:
for s in re.findall(r'(?<![0-9])[0-9]{5,6}(?![0-9])', line): # matches only 5/6 digit numbers
add.append(int(s))[/code]

The code won't cope with both adding and dropping in the same line. I think it chooses the last one it finds in the line.

Case shouldn't be an issue anymore.
If there are any words anyone wants me to add then please shout.