I've finished 3321933893 up to 76 bits, shockingly there were no more factors.

I've also taken 3321933541 up to 75 bits (I'm doing it a bit level at a time in case a factor drops out).

Also, I've been playing about a bit, rather a lot actually, and I came up with this:
[url]http://2721.hddkillers.com/compare/[/url]

Just wondering what you guys think, apart from, "Wow that's a really wide table." It basically compares the main statistics of OBD across both sites and finds the differences. I thought it might help in maintaining consistency across both sites.

That link is to the "offline" version which uses saved txt files of the sites, here is the "online" version:
[url]http://2721.hddkillers.com/compare/live/[/url]

Please don't hit that link too often, because every time you do it downloads 2 pages from More GIMPS (92KiB) and one from Eleven Smooth (53KiB) and I don't want to cause anyone any server issues.

The offline version usually loads in around 0.05 - 0.1 seconds, the online version usually takes around 2 seconds.

[QUOTE=lavalamp;173732]I've finished 3321933893 up to 76 bits, shockingly there were no more factors.

I've also taken 3321933541 up to 75 bits (I'm doing it a bit level at a time in case a factor drops out).

Also, I've been playing about a bit, rather a lot actually, and I came up with this:
[url]http://2721.hddkillers.com/compare/[/url]

Just wondering what you guys think, apart from, "Wow that's a really wide table." It basically compares the main statistics of OBD across both sites and finds the differences. I thought it might help in maintaining consistency across both sites.

That link is to the "offline" version which uses saved txt files of the sites, here is the "online" version:
[url]http://2721.hddkillers.com/compare/live/[/url]

Please don't hit that link too often, because every time you do it downloads 2 pages from More GIMPS (92KiB) and one from Eleven Smooth (53KiB) and I don't want to cause anyone any server issues.

The offline version usually loads in around 0.05 - 0.1 seconds, the online version usually takes around 2 seconds.[/QUOTE]

Thank you lavalamp.

The discrepancies come from a work that has been done on already factored exponents. I think that William decided not to update the current bit depth because it was not useful for the project (searching factors of Mersenne numbers with more than a billion digits). It was a cumbersome work to update all these exponents in less than 2 weeks.

Luigi

3321933451 from 72 bits to 74 bits.

Luigi

[QUOTE=ET_;173764]The discrepancies come from a work that has been done on already factored exponents. I think that William decided not to update the current bit depth[/QUOTE]

Hmmm. I don't recall having made that decision. Was this work reported in this forum?

William

It seems that the bulk of the differences do come from additional work on already factored exponents, however there is one difference for an inactive exponent, 3321928417. The two sites differ on how deeply it has been trial factored, and this is also responsible for the differing average bit depths between the sites in the first table.

I've completed trial factoring of 3321933541 to 76 bits and found no factors, continuing on to 77 bits now. I think this has pushed the level counter over the top now.

Level 10 Completed
 

[QUOTE=lavalamp;173805]I think this has pushed the level counter over the top now.[/QUOTE]

INDEED! :wblipp:

And automatically to 10.4 because four exponents are already at 77 bits or higher.

[QUOTE=wblipp;173814]INDEED! :wblipp:

And automatically to 10.4 because four exponents are already at 77 bits or higher.[/QUOTE]

Range 3321934000-3321935000 has about 54 exponents at 62 bits, of which 27 with factors.
Range 3321934000-3321936000 has about 97 exponents at 62 bits, of which 51 with factors.
Range 3321934000-3321936000 has about 145 exponents at 62 bits, of which 75 with factors.

Is it time to open a new range?

Luigi

[QUOTE=wblipp;173814]INDEED! :wblipp:

And automatically to 10.4 because four exponents are already at 77 bits or higher.[/QUOTE]Ahem :blush: this exposed a minor mistake I'd made with the find_goals function, it put the level at 10.05, but now it's been corrected and reads 10.04 as it should.

[QUOTE=ET_;173818]Range 3321934000-3321935000 has about 54 exponents at 62 bits, of which 27 with factors.
Range 3321934000-3321936000 has about 97 exponents at 62 bits, of which 51 with factors.
Range 3321934000-3321936000 has about 145 exponents at 62 bits, of which 75 with factors.

Is it time to open a new range?

Luigi[/QUOTE]There are still 109 unfactored candidates in this range, over three quarters of which are 73 bits or lower, are more needed?

[QUOTE=lavalamp;173820]Ahem :blush: this exposed a minor mistake I'd made with the find_goals function, it put the level at 10.05, but now it's been corrected and reads 10.04 as it should.

There are still 109 unfactored candidates in this range, over three quarters of which are 73 bits or lower, are more needed?[/QUOTE]

I'm working on taking 72s to 74s :smile:
Just think that if only one of them were prime, we would wait 500 years before opening a new range :razz:

I just thought that maybe people won't devote more than 48 hours' time of their machines to this whimsical project, and there are researchers gathering new Mersenne factors.

I'll be fine with AND without new ranges.

Luigi

[QUOTE=ET_;173825]I'm working on taking 72s to 74s :smile:
Just think that if only one of them were prime, we would wait 500 years before opening a new range :razz:[/QUOTE]Heh, well yes, but 109 of them?

Through a no-doubt deeply flawed method, I deduced that if all the unfactored 72, 73 and 74 bit candidates were brought up to 75 bits, 3 would be eliminated.

From the same method, I think that bringing 70 fresh candidates from 62 to 75 bits would eliminate 14.

These are computationally equivalent according to the More GIMPS CPU calculator (about 15.5K P90 years). The difference would be the number of candidates at 75 bits then. 96 in the first instance, 70 in the second.

So in the short term, I guess it depends on if you want to collect more factors, or take more candidates deeper. In the long term they are identical of course, since all these candidates will almost certainly be taken way past this eventually.

[QUOTE=lavalamp;173831]So in the short term, I guess it depends on if you want to collect more factors, or take more candidates deeper.[/QUOTE]

We already have a silly little rule to settle this. It's a silly little project - that's probably why I like the silly little rule. The problem is always the same problem lavalamp expresses - how do we decide when we need more candidates versus need more work on the existing candidates? The rule for sufficient lower level work is doubling candidates with each bit level. Our present level requires 10 candidates at 76 bits or higher, so the silly rule is 20 at 75 or higher, 40 at 74 or higher, etc:

[code]
Bits Target Actual
>= >=
76 10 10
75 20 23
74 40 [COLOR="Red"]25[/COLOR]
73 80 [COLOR="Red"]53[/COLOR]
72 all 109[/CODE]

It's a silly little rule we made up - if we don't like it we can make up a different silly little rule. It seems like a pretty good rule to me, though - it quantifies the idea that we can have lots of candidates away from the leading edge, but we shouldn't let them get too far away. I'm open to alternative suggestions, though.