[QUOTE=LaurV;278430]I don't quite really get that. How exactly is defined this "merges" and how you can detect it? From what I can see, the sequence started from 6 digits, but goes as low as 6 and 5 digits, so in that point the computing should end. Whatever factors have further, it would be already computed from the lower (5 digits) sequence. Am I missing something? [/quote]No, you're not missing anything. The important point to note, though, is which is the [I]lowest[/I] sequence that a higher sequence merges with since, by convention, we only count that lowest one as an open-ended sequence and the higher one as a [I]side-sequence[/I].

And the reason to do this is that as soon as a sequence merges, calculating both would be a waste, since they're identical from the merge on.[quote]For example:

[CODE]
Checked 1642 7 (show) 1129510 = 2 . 5 . 112951
Checked 1643 6 (show) 903626 = 2 . 193 . 2341
Checked 1644 6 (show) 459418 = 2 . 29 . 89^2
Checked 1645 6 (show) 261572 = 2^2 . 65393
Checked 1646 6 (show) 196186 = 2 . 233 . 421
Checked 1647 6 (show) 100058 = 2 . 7^2 . 1021
Checked 1648 5 (show) 74704 = 2^4 . 7 . 23 . 29
Checked 1649 6 (show) [COLOR="blue"]103856 = 2^4 . 6491[/COLOR]
Checked 1650 5 (show) 97396 = 2^2 . 13 . 1873
Checked 1651 5 (show) 86256 = 2^4 . 3^2 . 599
Checked 1652 6 (show) 155544 = 2^3 . 3 . 6481
Checked 1653 6 (show) 233376 = 2^5 . 3 . 11 . 13 . 17
Checked 1654 6 (show) 528672 = 2^5 . 3 . 5507
Checked 1655 6 (show) 859344 = 2^4 . 3 . 17903
Checked 1656 7 (show) 1360752 = 2^4 . 3 . 28349
Checked 1657 7 (show) 2154648 = 2^3 . 3 . 17 . 5281
[/CODE]Starting from T1644 to T1654, all the terms are smaller then 594228. The smallest is T1648=74704. They all "merge". We should only continue with that sequence (or with any other of them, dosn't really matter) and all the other, including T1643, T1654, T1655 (which are under a million) are in fact "done" for this project (of factoring aliquots with starting point under a million). What I am missing?[/QUOTE]Yes, but notice this from 38208:[code] 0 . 38208 = 2^6 * 3 * 199
1 . 63392 = 2^5 * 7 * 283
2 . 79744 = 2^7 * 7 * 89
3 . [COLOR="blue"]103856 = 2^4 * 6491[/COLOR][/code]A term that is higher than the minimum comes from a lower starting number.

This is the reason that we adopted 4788 as a group project. Wieb Bosma was actively pursuing sequences in the 250k-400k range up to a minimum of 100 digits. He posted a note [URL="http://www.math.kun.nl/~bosma/Projects/tabB.html"]here[/URL] that 314718 merged with 16100. I was interested in following up on this, so I generated the lines we did not have for 314718. When I sent them to Clifford, he checked further and found that 314718 actually merged with a lower starting number, 4788. And again, it was on a line other than the actual minimum.

314718:[code] 6458 . 50534 = 2 * 11 * 2297
6459 . 32194 = 2 * 16097
6460 . 16100 = 2^2 * 5^2 * 7 * 23 [COLOR="Red"]<--minimum[/COLOR]
6461 . 25564 = 2^2 * 7 * 11 * 83
6462 . 30884 = 2^2 * 7 * 1103
6463 . 30940 = 2^2 * 5 * 7 * 13 * 17
6464 . 53732 = 2^2 * 7 * 19 * 101
6465 . 60508 = 2^2 * 7 * 2161
6466 . [COLOR="Blue"]60564 = 2^2 * 3 * 7^2 * 103[/COLOR][/code]4788:[code] 0 . 4788 = 2^2 * 3^2 * 7 * 19
1 . 9772 = 2^2 * 7 * 349
2 . 9828 = 2^2 * 3^3 * 7 * 13
3 . 21532 = 2^2 * 7 * 769
4 . 21588 = 2^2 * 3 * 7 * 257
5 . 36204 = 2^2 * 3 * 7 * 431
6 . [COLOR="blue"]60564 = 2^2 * 3 * 7^2 * 103[/COLOR]
7 . 105420 = 2^2 * 3 * 5 * 7 * 251[/code]And again notice that the minimum is on a different line than the merge with a lower starting number.

And the reason that 314718/4788 became [I]very interesting[/I] is that at that point it was the longest sequence so far calculated because the 6000+ lines had the 2000+ lines calculated for 4788 added to its length. Up until a couple of months ago, it was far and away the leader for longest sequence.....now it's not the longest, but still most wanted since it has the highest downdriver acquisition ever.

Well, thanks for the explanation, now I got it better. In fact I think I am a bit of idiot, because first time when I read the 38k number in bchaffin's post, I understood it like a 380k number (still smaller then initial sequence head, but I really missed the number of digits, well, I am at job and had other problems to solve too, but this is not an excuse). The explanation you gave is however perfect and clear, and can stay so other stupid guy like me could understand what's going on.

edit: ps: I always wondered "why 4788?". Now this enigma is solved too.

@schickel: It seems that the previous version of the db used to be able to provide a list of all the side-sequences. Doesn't 4788 have several others besides the two you mentioned? (Memory-what a terrible thing sometimes!)

Is there a current way/location to find side-sequences, and isn't there a term for the entire set? Maybe, tree or family?

Yeah, that was a great explanation by schickel. In practice, here's how I detect a merge: I have a local copy of the elf files for all open sequences <1M. Then a very simple perl script just reads in all the elf files in numerical order, and sticks every composite into a big hash. If the hash entry is already defined, then it has detected a merge.

By only comparing against the known unique open sequences, this gets the right answer -- in this example, terms 1644-1648 aren't in the hash because they come from known side-sequences which aren't in my list. There's a little chicken-and-egg problem since you need a list of unique sequences to start with, but fortunately the nice folks here provided me with that early on so I had a starting point.

[QUOTE=bchaffin;278510]...

By only comparing against the known unique open sequences, this gets the right answer...[/QUOTE]
Sorry, but I'm missing something. Why only open sequences? Isn't it possible for a currently open sequence to merge with a terminated one, and subsequently terminate? Or, are you leaving that up to the db to take care of when you submit factors?

[QUOTE=EdH;278528]Sorry, but I'm missing something. Why only open sequences? Isn't it possible for a currently open sequence to merge with a terminated one, and subsequently terminate? Or, are you leaving that up to the db to take care of when you submit factors?[/QUOTE]

look at post 22 maybe ?


[QUOTE=10metreh;189474]I've listed it as a termination - I think it should only be a merge if the sequence that it merges into is open.

But this would cause problems if someone found a merge, countinued working on the merged sequence, and terminated it...

...but luckily we haven't had that happen yet.[/QUOTE]

[QUOTE=science_man_88;278532]look at post 22 maybe ?[/QUOTE]I'd have to go back and look again, but I think I was inclined to want to call it a merge rather than a simple termination because after it merged, the sequence went up before it went back down.

As far as finding merges, the first version of the factorDB code would indicate merges when you queried a sequence, indicating which sequence it merged with.

Aliqueit only indicates (and stops on, if configured) merges when a number falls below the starting value. As bchaffin stated, he uses a hash table to check sequences the workers work on, very handy.

The "old-fashioned" way is to check a [URL="http://www.aliquot.de/archiv/c9c30.zip"]file[/URL] on Wolfgang's site which contains, for every open sequence, the 9-digit numbers encountered while extending a sequence, along with the 30-digit numbers reached. If a sequence you extend drops below 9 digits, you can cross-reference the 9-digit number against the c9c30 file and see if it turns up in there.

A thrid way was found when I started pulling a complete status on all the open sequences from the DB. Several of us noticed that some sequences had the same status (size and small factors) without being on the same line...artificial example, this is 4788 & 314718 pulled tonight:[code] 4788 2758. sz 161 2 * 7 * 11 * 13 * 83
314718 9218. sz 161 2 * 7 * 11 * 13 * 83[/code]Unfortunately, this line has just a couple of small factors, but if there is one (or more) factor(s) above 10-15 digits, it becomes a little more certain that the lines are, in fact, identical and there has been a merge. Clifford has a utility on his [URL="http://www.lafn.org/~ax810/aliquot.htm"]page[/URL] that reads two sequences and finds the line where they merge, if it exists. (In UBasic, so it's very dated, but there hasn't been much call to update it.....)

The workers bag another one: [strike]543272[/strike] 543[COLOR="Red"]9[/COLOR]72 terminates at term 1853, after two peaks of 112 digits. A remarkably fast descent from the top!

[QUOTE=bchaffin;279348]The workers bag another one: 543272 terminates at term 1853, after two peaks of 112 digits. A remarkably fast descent from the top![/QUOTE]Man, you keep setting them up and mowing them down....nice work!

Ooops...wrong one! [I corrected the post.]

A Thanksgiving present: 701184 terminates in 1567 steps, from a Mt. Fuji-esque peak of 116 digits.

[QUOTE=bchaffin;280146]A Thanksgiving present: 701184 terminates in 1567 steps, from a Mt. Fuji-esque peak of 116 digits.[/QUOTE]Wow, so that makes 15 (or 16, depending on whether 219282 was done by your workers) for 2011 alone!

Nice record.....