More missed factors

[ATH]

Originally Posted by Madpoo

I've just never actually seen a 0.95 bit, so I wonder what that looks like. Is that like being almost pregnant?

Since bits are, by definition, binary, either 0 or 1, would it be fair to say that a 0.95 bit is really a full bit? Shouldn't it always round up when deciding how many bits are involved? LOL

You are stuck on the number of bits to represent the number, and that has nothing to do with GIMPS factoring ranges as we use the word differently / wrong.

Originally Posted by Madpoo

Example: M121116253

My query triggered on that because according to "floor(log(cast(@fact as float),2)+1)", the factor "286470483607240143641" has 68 bits. The actual value for "log(cast(@fact as float),2)" without the floor+1 is 67.9569483967743 (which matches what James' site has for it).

If I go by 67 bits, then it's GrunwalderGIMP is just fine because that's apparently where it found the factor, between 67 and 68 bits.

But of course you can't have a fractional bit, so yes, 67.95... bits is really 68 bits. So why didn't the client properly mark that one as found in the 68-69 range?

GrunwalderGIMP factored from 66 to 68 bits (the GIMPS use of the word) which means between 2^66 and 2^68.
2^66 = 73,786,976,294,838,206,464 and 2^68 = 295,147,905,179,352,825,856.
So the program looks for factors 2kp+1 between those 2 numbers, and since the factor he found was: 286,470,483,607,240,143,641 which is between those 2 numbers, then it was correctly found in the TF: 66-68 interval and not the 68-69 interval.

We say the factor is 67.9569483..... bits because log₂ (286470483607240143641) = 67.9569483..... and because 2^67.9569483..... = 286470483607240143641.

Forget everything about how many 0's and 1's it takes to write the number and just use log base 2 :-)

[Madpoo]

Originally Posted by TheMawn

286470483607240143641 = 2^67.957.... That is why it's a "fractional" bit.

My confusion is that I'm working backwards here... I'm looking at a factor, how many bits it is, and then looking at work done on that same exponent where it reported "no factor found from 2^x to 2^y"

In so doing, I'm looking at a factor like "286470483607240143641" and noting that it's a 68 bit number. As such, in my brain, it *should* have been found when someone was TF'ing between 2^68 and 2^69. In fact, for Prime95 that seems to be the case. It was *only* mfaktc that was doing it this alternate way by considering that factor to be in the 2^67 to 2^68 range.

I should probably confirm what I'm saying here, make sure Prime95 is actually doing what I think it's doing.

In my analysis, I'm raking in *all* of the "no factor found by TF" results and parsing out the "from 2^x to 2^y" information. If the "from 2^x" is missing I can't make any assumptions except that it must have started from the very beginning (I'm just defaulting to 2^2).

In my comparison then, I'm looking at the known factors, getting how many whole bits they are, and:
IF factor_bits <= from_bits AND factor_bits < to_bits THEN "I should have been found"

Like I said, this works fine on Prime95 clients, but fails miserably at mfaktc clients with thousands of false positives.

[Prime95]

Originally Posted by Madpoo

In so doing, I'm looking at a factor like "286470483607240143641" and noting that it's a 68 bit number. As such, in my brain, it *should* have been found when someone was TF'ing between 2^68 and 2^69.

No, testing from 2^68 to 2^69 is looking at 69-bit factors (2^68 is a 1 bit followed by 68 zero bits for a total of 69 bits).

[Madpoo]

Originally Posted by Prime95

No, testing from 2^68 to 2^69 is looking at 69-bit factors (2^68 is a 1 bit followed by 68 zero bits for a total of 69 bits).

Well apparently I've been thinking about it wrong... LOL

In fact I just did my own test of an exponent with a factor to see where Prime95 would find it. It's just like you said.

I tested M5212477 which has the known factor "4466244996994348319" (61.9537681007035 bits)

Since it's a 62 bit number I thought it would have been found in the 2^62 - 2^63 range, but yeah, it was found in the 2^61 - 2^62 range.

Well crumb, I guess I just need to adjust my query. I guess in the cases I was looking at last night where I thought it was working fine it was probably just incidental, where the user had tested ranges of numbers and managed to miss the factor anyway. Go figure.

EDIT: By the way, that exponent is a case in point of someone doing a test in a certain range and apparently missed a smaller factor in a range that hadn't been tested?

[Madpoo]

Originally Posted by Madpoo

Well crumb, I guess I just need to adjust my query. I guess in the cases I was looking at last night where I thought it was working fine it was probably just incidental, where the user had tested ranges of numbers and managed to miss the factor anyway. Go figure.

Okay... so now instead of looking at the # of bits a factor has, I'm looking at the log base 2 of the factor and just seeing if that's between 2^x and 2^y as reported by the client.

To start I still excluded the mfaktc clients so I could compare to the previous results. As noted it's mostly the same because the same user tended to test multiple bit depths, and there are a few more that weren't seen before.

As before, sannerud.com has a lot. 200 out of the 229 total. User "KYOJI_KAMEI" has 12 of the remaining 29, George has 4, and then just one or two for other users.

Example: M58127191

When I include the mfaktc clients, I still get some puzzling results:
M8217973

As you can see there, the user reported "no factor from 2^63 to 2^64" even though that same user also reported the factor with a bit size of 63.016.

So based on that is it fair to say that user did indeed miss it on that first run, and maybe ran the same range again and found it? On the same date?

In fact, that one user accounts for 2760 of the total 2939 "hits" for just mfaktc clients (a particular app version in the database anyway... app id #35 if George wondered). I suspect most of the factors that were found were found by that same person, so maybe it was a weird build that was reporting both a "no factor found" *and* a "factor found" for some reason.

User "Never Odd Or Even" has 35 total e.g.:
M1026391 (found later by someone else doing ECM)

User "Piepen" has 110 e.g.:
M56291771 (user also reported the factor in this case)

User "Axelsson" has 19 e.g.:
M601959719 (again, the same user reported the factor, 11 days later)

[Prime95]

Originally Posted by Madpoo

In fact, that one user accounts for 2760 of the total 2939 "hits" for just mfaktc clients (a particular app version in the database anyway... app id #35 if George wondered). I suspect most of the factors that were found were found by that same person, so maybe it was a weird build that was reporting both a "no factor found" *and* a "factor found" for some reason.

There is an mfaktc option to continue searching for factors at the current bit level after a factor is found. The option is off by default. Perhaps this person turned that option on and perhaps mfaktc outputs both the no factor and factor found lines when the option is enabled.

[Madpoo]

Originally Posted by Prime95

There is an mfaktc option to continue searching for factors at the current bit level after a factor is found. The option is off by default. Perhaps this person turned that option on and perhaps mfaktc outputs both the no factor and factor found lines when the option is enabled.

Could be. I had an inkling that I should check and see in these cases if the same user was the one that actually found the factor. If so I'll just consider it "ok" and then see if there were other users where it seems like they just plain missed it.

Overall, on first glance, it seems like maybe that user "KYOJI_KAMEI" might have had some issues since there seemed to be an unusual amount of false negatives in there (12 of them). Beyond that, I couldn't say whether the mfaktc results are relevant or not until I do that extra check.

EDIT: Indeed, after double-checking who actually submitted the factor eventually, user "KYOJI_KAMEI" missed all 12 and someone else found them.

For the mfaktc clients, user "1997rj7"had 4 missed runs, "Axelsson" had 2.

"Never Odd Or Even" has 14 where "no factor found by TF" but then he later found a factor by ECM. The other 17 were "no factor found by TF" followed by a "factor found by TF"

All of those by "Carsten Kossendey" were mostly found by him, but sometimes he found the factor by a different method, like P-1, and on the same day as he checked in the "no factors by TF" result. Kind of weird. 121 of his where TF didn't find it were found by him using P-1, with the other 2640 by him showing up as "no factor found by TF" *and* "factor found by TF".

[Madpoo]

Originally Posted by Madpoo

"Never Odd Or Even" has 14 where "no factor found by TF" but then he later found a factor by ECM. The other 17 were "no factor found by TF" followed by a "factor found by TF"

Oh yeah, and 4 for "Never Odd Or Even" had a factor found by someone else entirely.

[LaurV]

Grr, you people!

gp > #binary(286470483607240143641)
%1 = 68
gp >

This is 67 to 68 bits, i.e. 2^67 to 2^68-1
Analogy, think about why 4 to 7 are 3-bits numbers.

[edit: sorry, didn't see the lot of the discussion after! (3 pages? ) going back to read it!]
[edit2: this is "half credit" if done by mfaktc, is found after half of the time:

gp > ((286470483607240143641-1)/(2*7801993))%4620
%3 = 2420

[LaurV]

Originally Posted by Madpoo

Seems like 2^66 to 2^69 is missing.

Originally Posted by Gordon

It's 74.7 bits, TF stopped at 65 bits.
My question is, what are the chances of their being a factor between 65 & 75?

Zero, of them being TF-ed between those ranges. Those are P-1 factors, luckily (or unlucky?) small, only few bits over where the TF front was at that time. When the factor was found, the factoring stopped. If you ask about chance of existing a factor, roughly 1/65+1/66+....+1/75, minus bout 3% from the "P-1 was done".

[LaurV]

Originally Posted by Madpoo

As you can see there, the user reported "no factor from 2^63 to 2^64" even though that same user also reported the factor with a bit size of 63.016.

So based on that is it fair to say that user did indeed miss it on that first run, and maybe ran the same range again and found it? On the same date?

In fact, that one user accounts for 2760 of the total 2939 "hits" for just mfaktc clients (a particular app version in the database anyway... app id #35 if George wondered). I suspect most of the factors that were found were found by that same person, so maybe it was a weird build that was reporting both a "no factor found" *and* a "factor found" for some reason.

Or the user decided that the credit given for the factor is too small, especially if it was in a lower side of the range, but in a higher class, (i.e. you get almost no credit if the factor would be found very fast by P95, but it is in 4619 class and it takes for mfaktc almost all the bitlevel time to be found), and he (the user) decided to "improve" his credit. I confess that I was thinking to this for a while , as it does not negatively impact the project, yet you get your number of factors and a higher credit . At the end I gave up because implied too much work, especially after Misfit era. I am credit whore, but not so much...

[edit, otoh, I long time suspected Nooe of foul play, see former posts, nobody jumps to the first place in ECM tops in so short time..., but George said he knows the person and it is a honest user, see the discussion about the 383....83 exponent]