Figuring Out Sequence Merges

[Jayder]

I've searched hard for information, but I can't figure out how you can discover if a sequence has merged or not, and if so what sequence it has merged with.

I ask because it seems that somebody, within the last day, has started working on the sequence I have been working on (link). I suspect a merge has occurred, but despite my noobish efforts I am unable to find out more.

I have not reported anything new to factordb since I first noticed the possible merge, and yet it has progressed by more than 100 iterations. This has to be a merge, right?

Thank you for any help you guys can provide.

[LaurV]

There is no merge, you got a downdriver at term~2200 and went under 110 digits, therefore the elves or some dd-hunter took it. Right now, with D3 (2^3*3*5) since term ~2500, they left it (one of the most freaking drivers, due to the fact that is difficult to get rid of it, and the increasing of the sequence is faster than most other drivers).

[kar_bon]

Originally Posted by Jayder

I've searched hard for information, but I can't figure out how you can discover if a sequence has merged or not, and if so what sequence it has merged with.

What I do:

- download all last lines of the seqs upto yours from FactorDB
- compare them with yours

or
- if your seq falls down under 80 digits or more
- go to this site
- download C9C30, C60 or C80 (see section 'Databases', not up to date)
- search for your Cxx

[Jayder]

Originally Posted by LaurV

There is no merge, you got a downdriver at term~2200 and went under 110 digits, therefore the elves or some dd-hunter took it. Right now, with D3 (2^3*3*5) since term ~2500, they left it (one of the most freaking drivers, due to the fact that is difficult to get rid of it, and the increasing of the sequence is faster than most other drivers).

I had discounted random workers (elves?) because several large-ish numbers had been factored (100+ digits) which the database won't do and for the elves to hit as many 100+ers in my sequence as they did would seem very rare. I hadn't considered a poacher, but that makes sense. It's saddening that somebody would do that if it was done intentionally.

Thank you both for your help.

[EdH]

OK, I guess I need some more education...

Why would you only search for merges less than your number? In the case of 154548, I find it as the smallest in a family that includes over 50 sequences below 1M:

156018, 156030, 165210, 179886, 231366, 231378, 236370, 237846, 241206, 244146, 258606, 272514, 307614, 310218, 313314, 313998, 316182, 316194, 322194, 322206. 325362, 330978, 330990, 338128, 378126, 394848, 410832, 423870, 464308, 498836, 516228, 558498, 558510, 602130, 612930, 688332, 697026, 698300, 704814, 759312, 762546, 781986, 811362, 817228, 822594, 843054, 858174, 867666, 867678, 870148, 886276, 945328, 997666

154548 and all the above show their last lines equal in the db. Couldn't any one of the above numbers have been worked by someone, who did not realize they were also working 154548?

[kar_bon]

Originally Posted by EdH

Couldn't any one of the above numbers have been worked by someone, who did not realize they were also working 154548?

Anyone from this forum?
I think not, because all open (smallest) sequences are known, so he/she will take only those.

Anyone from 'outside'?
If so, you'll notice that the smallest seq (here 154548) will grow, too, and there's nothing against doing so. If he/she will terminate say 156018 (because he/she is running this instead 154548) the only thing which is noticed for history is the termination of 154548 for exmple on W.Crayaufmüller's page and perhaps the name (if known) of the terminator (no, please no reply on this, it's not Arnie).

[LaurV]

Originally Posted by EdH

Why would you only search for merges less than your number?

You don't. We check for merges in the same way you did, looking at the last number in the sequence. Historically, because they were a million and no data base available (with all the factors) some lists were made, which record for example "the first 10 digit number" reached by a sequence. Most of the million sequences do not reach a 10 digits term, but if your (new) sequence do, you look in the list if it is a merge. Very easy to check. Then, a 30-digits list was done, or a 50 digits list. This way one don't need to search all the factor data base (in fact, we don't have such a database, FDB is bloody to search). The advantage of a list is the fact that such list is fixed, once the remaining sequences pass over the threshold, and do not need to be maintained, except rarely (if a sequence goes under 50 digits, for example, and came back over it, a new term will be added to the list). There was a list of "first reach 100 digits" too, but that is not used so much anymore, because at the time when the "remaining sequences" reached 100 digits, very few survived, and a list with last term is easy to get from the DB now. The problem is that the DB is not very well maintained, Sid is always busy when you need him... People report the results seldom, they don't report downdrivers till the downrun end, because they are afraid of ddhunters, etc.

Dubslow's site was a good resource, but is down since some time. Therefore I keep my own lists. I would like to host/mirror Dubslow's page, for example, it will not be a big deal of trafic, it may not be available 24/7, but most of the time will be available, and any positive number is better than zero... but I can't contact him. Also, I am sure other people here could host that page too, better than me...

Couldn't any one of the above numbers have been worked by someone, who did not realize they were also working 154548?

Only if he didn't know what he was doing. The sequences in your list, once reported as mergers (all were known), they are eliminated from the reservation list. For example, I start working 279936, because I liked it (it is 6^7, perfect number at odd power, blah blah) which, after a lot of adventures, merged with other sequences, the smaller of them being 95280. I kept the reservation for 95280, but the other were erased from the list. They are not available for reservation anymore. For the same reason you can not reserve for example sequence 396, neither is this listed as one of Lehmer fives, because is a merger with a lower sequence (276) and therefore 396 does not appears in the list anymore. Of course, someone can work the sequence 396, but only if he doesn't know what he is doing. Or if he poaches.

[EdH]

@LaurV

Originally Posted by kar_bon

What I do:

- download all last lines of the seqs upto yours from FactorDB
...

(emphasis added by me) This was why I asked...

@all:

Thanks for the replies, but I must be a bit dense. Did Dubslow's page take merges into account and only show the primary number? Other than checking for merges, via the db or various other data, how would I know not to reserve a higher sequence? Would I be "scolded" if I reserved a higher sequence without noticing/checking for a merge? Does any of this mean that I should always check for merges as well as reservations prior to reserving?

I use endings for my last line list, which I believe should be up-to-date and easier on the db than separate calls. Is endings.zip also up-to-date, or is it an earlier run? And, are the holes in these lists (like, 58501-58600) there for some particular reason?

Thanks for all the replies...

[LaurV]

Originally Posted by EdH

Did Dubslow's page take merges into account and only show the primary number? [yes, after manual confirmation. before manual confirmation, the sequences were still shown, but instead of the terms/drivers it said "merged with blah blah"; after manual confirmation, the higher sequence is gone.] Other than checking for merges, via the db or various other data, how would I know not to reserve a higher sequence? [you don't, beside of keeping your own list]. Would I be "scolded" if I reserved a higher sequence without noticing/checking for a merge? [no, some one like Frank would be delighted if you progress any sequence , there is plenty of work for everyone. Someone else will tell you about the merge, if you report your reservation/progress, and if the head sequence is reserved already, you will have to negotiate with the owner who is keeping it. Some guy may be nervous about "hey, let my sequence alone", but that's life. If the guy is me, I will thank you, and let you have it, hehe] Does any of this mean that I should always check for merges as well as reservations prior to reserving? [better check!]

My comments in square brackets, I am left handed in handling multiple quotes right now. :D
[edit: if you reserve the sequence here, someone will tell you about the merge, for sure. Few people here keep a very strict evidence, only they don't read the forum everyday like us, they have more important things to do, but someone will notify you for sure]

[edit2: about that "last lines", you must be really lucky to run in a merge with a last line of a sequence - never happened. Otherwise you have to report every factorization to the DB, and check if the DB has a "progress" of your sequence of more than expected lines. We usually don't work like that, it is very time-consuming, we do many terms between reports, and only check for merges when the sequence runs down (decreases) many terms, or when we see jumps in the DB which are not explained by our factoring power. Connected to this is the fact that you don't really need the "endings" to be very updated. Your chance to have a merge to "last term" is null]

[schickel]

Originally Posted by EdH

I use endings for my last line list, which I believe should be up-to-date and easier on the db than separate calls. Is endings.zip also up-to-date, or is it an earlier run? And, are the holes in these lists (like, 58501-58600) there for some particular reason?

Thanks for all the replies...

Probably not. For 7044 it shows this:

7044: 1824550790021816183454859929959773536447055697508964211261232126949397733460093201749101092576020395754873344507860668024966763208122497731062434064 @n=1397

It is actually:

  7044  3433. sz 180 2^9 * 3 * 11 * 31 * 3673

[EdH]

Originally Posted by schickel

Probably not. For 7044 it shows this:

7044: 1824550790021816183454859929959773536447055697508964211261232126949397733460093201749101092576020395754873344507860668024966763208122497731062434064 @n=1397

It is actually:

  7044  3433. sz 180 2^9 * 3 * 11 * 31 * 3673

So, both endings and endings.zip (which seem to be the same) are rather outdated...

I wonder if they are just a snapshot from when Syd created them, rather than a function that runs when called...