Well that didn't take long, somebody just looked up
[url]https://www.mersenne.ca/factor/3422053571247618385904165377[/url]
via the factor-bit-size box on mersenne.ca
Presumably [i]mikr[/i] who just found the factor via P-1. The factor and effort will naturally be imported during the next overnight data sync. I still doubt we'll (ever?) see an actual Mersenne factor entered that someone wouldn't also report to mersenne.org or mersenne.ca but at least I know this current implementation works.

1G range completed to 55bits with ~4.1M new factors using mfaktc

Hey James, just out of curiosity, how/how often do you synch mersenne.ca factors from primenet for the <1G range? Is there an export page from primenet?

[QUOTE=hansl;521896]Hey James, just out of curiosity, how/how often do you synch mersenne.ca factors from primenet for the <1G range? Is there an export page from primenet?[/QUOTE]Data submitted to mersenne.org is packaged up nightly at a url like
[url]https://www.mersenne.org/result_archive/2019/2019-07-18.xml.bz2[/url]
which mersenne.ca parses within a couple hours after midnight UTC.
I can't find the original thread where Aaron created this export, but [url=https://www.mersenneforum.org/showthread.php?t=20848]this thread[/url] discusses it somewhat, including the yearly archives.

Thanks for the info.

On another unrelated issue/question (but related to discussion from previous page of this thread), I think there is still some error with the "% Known" calculation on the "many factors" page:

From here: [url]https://www.mersenne.ca/manyfactors.php?s=n&o=d&p=350[/url]

The page includes these exponents, % Known values:
M1361 95.7866608031%
M2087 72.9985081675%
M2677 49.3949485006%

However clicking to each individual page for those says they are fully factored:
[url]https://www.mersenne.ca/exponent/1361[/url]
[url]https://www.mersenne.ca/exponent/2087[/url]
[url]https://www.mersenne.ca/exponent/2677[/url]

Any idea what is going on there?

edit: It looks like the offending exponents also show "Largest factor (bits)" equal exactly 1024.00, so some kind of overflow issue when the prime cofactor is too large?

[QUOTE=hansl;522007]Any idea what is going on there?[/QUOTE]No immediate idea, but I see the "largest factor" is showing as the suspicious value of 1024.00 which seems unlikely. I'll have to investigate to find where or why that's happening.

edit: seems I cross-posted with your edit :smile:

The error appears to be coming from MySQL, where the LOG2 function doesn't return anything larger than 1024. I have similar notes from a long time ago that the PHP [url=https://www.php.net/manual/en/function.log.php]log[/url] function also doesn't work above 1024-bit.

It seems that [url=https://www.php.net/manual/en/ref.gmp.php]PHP-GMP[/url] doesn't implement any logarithm function, although perhaps someone with more than my grade-school arithmetic can tell me how to cobble together something that will give the log2 of a number larger than 1024-bit using available functions? The only thing I have right now is the approximation:[code]strlen($factor) * log(10) / log(2)[/code]

For now, if the final factor exceeds 1023-bit then I'm using the slightly-imprecise float values stored in the database so you'll get things like 99.99999829% factored, but I suppose that's better than 95%

I don't really know how what sort of datatypes are used to handle these big numbers in mysql or php (and thus the exact operations available), but you could possibly get a reasonable value with a loop, like this pseudocode:
[code]
extra = 0.0
bits = log2(bignum)
while(bits == 1024) {
bignum = bignum / (2^512) # (alternatively use logical shift right if possible "bignum = bignum >> 512")
extra = extra + 512.0
bits = log2(bignum)
}
return bits + extra
[/code]

I divide by only half the max bits so there is still some precision remaining in case the number is very close to 1024 bits.

If its stored, and converted from/to some decimal string representation, it might be easier to strip the last so many decimal digits in the loop instead of doing long division.

So if you strip off the last 154 decimal digits for example, this would be the closest to 512 bits:
log2(10^154)==511.57692661265380157202919214136608708

Then instead of adding exactly 512.0 to "extra", you would add that value above.

edit: By the way, 1023 is the maximum binary exponent available for double precision floating point( because it uses a signed 11bit exponent), which is probably why you only get 1024 max from log2. [url]https://en.wikipedia.org/wiki/Double-precision_floating-point_format[/url]
I'm assuming there's some point where your big number gets converted to double in order to pass into log2, and when it converts a large enough value to double it usually ends up as the floating point representation for "infinity"(basically signaling "out of bounds"), and I guess log2(infinity) returns 1024.00

For the last 12h or so, I have been getting an Internal server error every time I try to access mersenne.ca, regardless of the device used. Is it just me?

[QUOTE=lycorn;522145]For the last 12h or so, I have been getting an Internal server error every time I try to access mersenne.ca, regardless of the device used. Is it just me?[/QUOTE]

I was almost about to say that it's just you... because none of the TF1G jobs showed errors, and the assignment and submission pages work. But yeah, for whatever reason, the main page ([url]www.mersenne.ca[/url] with nothing after it) gives error 500. Exponent status pages seem to work, too, if you know how to form the URL, or have a link from somewhere else.