M7090613
Factor: 73788858748680091871 / TF: 66-67

In binary, this factor is
1000000000000000110101100000001010011110000100011010011100011011111
That's 15 zero bits after the first 1.

This factor is only 0.0026 % above the limit of the previous TF search, which was 2[SUP]66[/SUP] = 73786976294838206464

PrimeNet awarded a magnificent 0.0001 GHz-Days credit.

Ha! B-e-a-utiful find!

The difference is so small that it totally confuses James' site, which probably uses \(ceil(log_2(q))\) to calculate the number of bits, and there is not enough precision, or the 64 bits php variable is used, because the size is (wrongly) displayed as 66 bits. :rofl:

Anyhow, the right formula to be used should be \(floor(log_2(q))+1\), which also solves the problem when q is a whole power of 2 (for example, 2^2 has 3 bits). That should compensate for the low precision of the calculus (the difference between ceil and floor+1 is only when applied to an integer, and it always works when lower precision, because of the lower precision is done by truncation, in this case. If that is done by rounding, it will not work for numbers close to integers, but smaller than them, like 0.99999, etc).

OTOH, the "k" of this factor is in class 175 of both 4620 and 420 classes, so if you used the 4620 (most probable) then you found it quite fast, after only 175/4620 = ~3% of the time, so you should not complain for the low credit given :razz:

But if you used 420 classes, you were unlucky son of a gun, you wasted a lot of time for it!

edit 2:
[code]
gp > ceil(log(q)/log(2))
%5 = 67
gp > log(q)/log(2)
%6 = 66.00003680557622102416872376
gp > default(realprecision,3)
gp > log(q)/log(2)
%8 = 66.0
gp > default(realprecision,5)
gp > log(q)/log(2)
%10 = 66.000
gp > default(realprecision,7)
gp > log(q)/log(2)
%12 = 66.00004
gp > #binary(q)
%13 = 67
[/code](here ceil is used as I know q is not a power of two; please note that pari's internal precision is never smaller than 15 decimals or so, even when you set it smaller, it is only used for printing, and not for calculus; for calculus he always uses his doubles)

[QUOTE=LaurV;440627]OTOH, the "k" of this factor is in class 175 of both 4620 and 420 classes, so if you used the 4620 (most probable) then you found it quite fast, after only 175/4620 = ~3% of the time, so you should not complain for the low credit given :razz:[/QUOTE]

Yes, it was mfaktc with 4620 classes, it found it at class 175 and 3.9%.

P-1 found a factor in stage #2, B1=665000, B2=12635000.
UID: Jwb52z/Clay, M79221677 has a factor: 8331269112412704936246407 (P-1, B1=665000, B2=12635000)

82.785 bits.

[QUOTE=LaurV;440627]The difference is so small that it totally confuses James' site, which probably uses \(ceil(log_2(q))\) to calculate the number of bits, and there is not enough precision, or the 64 bits php variable is used, because the size is (wrongly) displayed as 66 bits. :rofl:[/QUOTE]The site displays 66.000 because it's right :razz:

The PHP code uses [i]log(floatval($factor), 2)[/i] to calculate the bitsize, and on my server it would return that as "66.000036805576", so a little less precision than what you calculated but appears to be right. The limiting factor is actually the single-precision FLOAT column in the MySQL table that stores the factors, but since I'm only displaying 3 decimal places I figured it's plenty close enough.

edit: on the [url=http://www.mersenne.ca/exponent/7090613]exponent page[/url] if you now mouse-over the 3-decimal displayed bit size you'll get the 12-decimal more-precise version if you're so inclined. And you'll have to Ctrl-F5 forcibly refresh if you have previously looked at the page since it's heavily cached.

[QUOTE=James Heinrich;440756]The site displays 66.000 because it's right :razz:

The PHP code uses [i]log(floatval($factor), 2)[/i] to calculate the bitsize, and on my server it would return that as "66.000036805576", so a little less precision than what you calculated but appears to be right. The limiting factor is actually the single-precision FLOAT column in the MySQL table that stores the factors, but since I'm only displaying 3 decimal places I figured it's plenty close enough.

edit: on the [url=http://www.mersenne.ca/exponent/7090613]exponent page[/url] if you now mouse-over the 3-decimal displayed bit size you'll get the 12-decimal more-precise version if you're so inclined. And you'll have to Ctrl-F5 forcibly refresh if you have previously looked at the page since it's heavily cached.[/QUOTE]

right but if it's base 2 log is greater than 66 then it is greater than 2^66 which actually has 67 bits to it's binary representation.

[QUOTE=James Heinrich;440756]The site displays 66.000 because it's right :razz:[/QUOTE]
No, it is not. You didn't get my point. If you go for 3 decimals precision, then you should round them up, unless they are already integer, when you have to add 1.000 (this never happens for factors, as they are never a full power of 2).

The value you currently display would give the FALSE impression that the factor is 66 bits, when in reality is 67. Therefore, truncation is wrong ("truncation" as in rounding down, or ignoring the other decimals, or floor function, and opposite to rounding up, or ceiling functions). [U][B]You should display 66.001[/B][/U], and in that case we will know is 67 bits. Everything that its fractional is smaller than 0.001 should be displayed as 0.001.

But the patch with mousing over is also satisfactory. Not perfect, but satisfactory.

edit: Best would be to have it rounded up, AND the patch with mouse hovering. Not all people do mouse hovering there. But if we see it is 66.001, so it is higher than 66, then we can mouse over if we want to see the real value. Never display "integers" unless they are really integers, AND unless they really represent the number of bits. Otherwise the title of the column is very misleading. Float values are ok, everybody knows that 13.123 is 14 bits. But 13.000 is 13 bits. Not 14.

IMO, "bits" is always an integer and in this case would be 67. The data presently displayed in the column would be more properly be labelled log2(factor) and is correctly output as 66.000.

Of course "log2(factor)" is a lot of characters for a column label. So, perhaps the web page designer is allowed a little leeway in order to make a prettier web page. Maybe "bits[SUP]*[/SUP]" with a footnote explaining the mess or simply "log2" would be an alternative.

I now display 3 decimal places, unless those 3 show up as ".000" in which case I automatically show as many as needed to have a non-zero as the last digit. In the case of [url=http://www.mersenne.ca/exponent/7090613]M7090613[/url], it now displays "66.00004". Of course the mouseover 12-digit precision is still there, and I have added a red asterisk to the column header saying it's really log2(factor) and not real bits.

Does that work for everyone?

Works to me. Note that the full decimal expansion was also shown in the graphs with the factor bounds, where is (and always was) correct, when mouseover the big dots (there, the expansion is more suggestive, due to the graphical view).

Good job James! (as usual)

edit: however :razz: can you make it tooltip, i mean square corners and yellowish background, like the other columns? As opposite of "button" style, with round corners and white background, which it is now. The motivation is not only aesthetic, but the tooltips come instantly when you mouseover. The "button" you just added has a delay (lag) of about half second, which is bothersome, you have to "know" that is there, otherwise you don't wait for it and you lose it.

Congratulations to Anton Repko, who found a (first) factor for [URL="http://www.mersenne.org/report_exponent/?exp_lo=26711&full=1"]M26711[/URL].

And also there is a fourth factor for [URL="http://www.mersenne.org/report_exponent/?exp_lo=4957&full=1"]M4957[/URL]. The cofactor is not probable-prime.