[QUOTE=ixfd64;515567]I'm guessing this is because the factors are so large that they cause an overflow when the server tries to calculate how much credit to give. However, this wouldn't explain why there is a small amount of credit as opposed to no credit at all.[/QUOTE]

If PrimeNet is not told how many curves were run to find the factor is has assume only 1.
Further, I can't recall if Ryan's results give the bounds run. If not PrimeNet has to assume something. This might explain the low credit.

[CODE]
python3 -c "x= 10819968927585403636958816179849566933560096066787125831 ; print(x.bit_length())"

183
[/CODE]

Any calculation that uses log to determine bit size inevitably has rounding errors for very large numbers that are close to a power of two, where you get a result that is off by one. The [c]bit_length()[/c] result is always exact.

a new P43 factor was found in M3373 by... guess who?

If you guessed Ryan, you were wrong, it was James Hintz. The cofactor is still composite.

(You could have actually guessed James Hintz correctly, because he is responsible since the start of the year for factors that finished full factorization of M3203, M3089, M6679)

[QUOTE=DukeBG;515714]a new P43 factor was found in M3373 by... guess who?

If you guessed Ryan, you were wrong, it was James Hintz. The cofactor is still composite.[/QUOTE]

Ryan has only been finding factors of 55 digits or more. A mere 43-digit factor is like a penny on the ground that's not worth stooping to pick up. :smile:

Actually, Ryan seems to be focusing on unfactored exponents, which obviously already had pretty deep ECM done on them already. Whereas exponents like [M]M3373[/M] already had prior factors.

Ok, that's fair :grin:

[QUOTE=retina;515614]Python can also be coaxed to do this for you locally[/QUOTE]As can PHP:[code]> php -r "echo log(10819968927585403636958816179849566933560096066787125831, 2);"
182.81974157489[/code]

This is a personal best for me, to date:

[CODE]M83621 has a factor: 350415918423517661715474499722683369441 (ECM curve 1, B1=1000000, B2=100000000)[/CODE]128.042 bits.

:smile:

[QUOTE=storm5510;515818]This is a personal best for me, to date: 128.042 bits[/QUOTE]Not bad! I've only ever found 1 factor fractionally bigger ([SIZE="1"]128.605[/SIZE]), and I've never found an ECM factor. :down:

[QUOTE=James Heinrich;515837]Not bad! I've only ever found 1 factor fractionally bigger ([SIZE=1]128.605[/SIZE]), and I've never found an ECM factor. :down:[/QUOTE]

I have found only 12 out of 10,000+ ECM runs. Someone here once described this process as throwing darts at a dartboard. In this case, the dartboard is 50 feet away.

P-1 found a factor in stage #1, B1=700000.
UID: Jwb52z/Clay, M91556807 has a factor: 177424028897961775771913 (P-1, B1=700000),

77.232 bits.

After the latest factor found in the ranga 0 - 1M, exactly 80% of the numbers in that range are factored!
It was a 150-bit factor for M16369, found by... Ryan Propper.