5G range completed to 55 bits, with 4,475,607 total new factors found between 5e9 and 6e9.

I've switched the main producer over to slightly slower 4G range, which it will do only for a few days up to 4294M, after which I'll put it back on much slower 2G range.
Another computer is already working on 4295M+ (basically > 2^32 which I switched it to as added precaution when you asked for > 4G, and before I was filtering known factors).

[QUOTE=James Heinrich;520952]No, I removed the 4-factor list a few weeks ago...[/QUOTE]Huh? what's that with 99.6% (and other numbers lower than 100%) that appear (in green) for very small expos for which the mersennes are totally factored? How did you get to lower than 100% there?

[QUOTE=LaurV;521400]Huh? what's that with 99.6% (and other numbers lower than 100%) that appear (in green) for very small expos for which the mersennes are totally factored? How did you get to lower than 100% there?[/QUOTE]That was actually "99.9999996143", don't underestimate it. :wink:

It's just a display/rounding error from lack of precision in the database. I have switched the factor bits columns from FLOAT to DOUBLE now, and also taken extra trouble to precisely calculate the size of the final factor so it should correctly display "100.000000000%" when the exponent is fully factored [SIZE="1"](well, it should at least 99.9999996143% of the time)[/SIZE].

[QUOTE=hansl;521382]5G range completed to 55 bits, with 4,475,607 total new factors found between 5e9 and 6e9[/QUOTE]Good work! The queue is holding up fine now. If you see it slower sometimes than others it's because I'm also hammering the factor tables for other, unrelated updates (that will take several weeks). But whenever I see more than 100k in the queue I'll run a manual extra job to get the queue count back down again, so all is well in hand. Keep the factors coming!

[QUOTE=James Heinrich;521421]
It's just a display/rounding error from lack of precision in the database.[/QUOTE]
Much better now! All green stuff in all tables show 100%.

(technically, you could round it "early" don't need to do it at so far decimal, because the remaining part can't be lower than the lowest prime factor, which has at least log2(p)+1 bits, so if you get into 100*(1-epsilon), then this is 100, it can't be intermediary)

Real random thought:

If at Mersenne.ca someone ask to look-up the size of a factor:
Would it be worthwhile to first, check that it is odd, then look up if it was a known factor, if not;
. calculate the k*p value and then attempt to match it to a p

:question:

This way we might 'find' some new factors from the inquiry.

If somebody attempts to look directly look up a factor (e.g. random example: [url]https://www.mersenne.ca/factor/277012885453224551[/url]) that is not in the database then it will be checked and matched to the appropriate exponent if applicable.

But not if they are just checking the size and not looking it up, no, correct? (They could be doing that on numbers that aren't factors.)

[QUOTE=Uncwilly;521466]But not if they are just checking the size and not looking it up, no, correct? (They could be doing that on numbers that aren't factors.)[/QUOTE]If they don't click the "Look up exponents with this factor" below the factor size box, no. I could potentially make it do that, but it would have to be some kind of AJAX request fired off in the background since the factor bitlength is instantly calculated in javascript and not normally known to my server at all.

Ok, it was just a real random thought.

Random thoughts are good. The chance of discovering a new factor this way that's not being reported elsewhere is (very) low, but sure, why not. Implemented now. If one is ever found I'll be sure to let you know :smile: