wrong count of assigned TF?

[rudi_m]

Hi,

I wonder about Work Distribution Map, range 87M-88M.
It shows 9 exponents assignend to TF but when I check that range completely I see only 8 assigned exponents.
Maybe this is a bug?

cu,
Rudi

[Uncwilly]

They are probably hiding a newly discovered prime there.

[cheesehead]

Originally Posted by rudi_m

when I check that range completely I see only 8 assigned exponents.

Using "Exponent Status", I checked the first 500 exponents after 87000000 (through 87009029). It showed the 8 TF assignments from 87000127 through 87000413.

How did you check the rest of the whole range from 87M to 88M? I know only the "Exponent Status" page, which shows no more than 100 exponents at a time -- is there some other way I'm missing? (or are you really, really patient?)

[rudi_m]

Originally Posted by cheesehead

How did you check the rest of the whole range from 87M to 88M? I know only the "Exponent Status" page, which shows no more than 100 exponents at a time -- is there some other way I'm missing? (or are you really, really patient?)

I wrote a little script to download bigger exponent status ranges.
But you can see the Problem also in two other ways:
1. using http://www.mersenne.org/report_factoring_effort/
to download simple text report of 87M-88M (factored range 0-999) including as well as excluding currently assigned exponents.
Then diff both texts.
2. checking http://www.mersenne.org/primenet/
There are 24012 non-LLs but 24004 available for TF and 9 assigned TFs (=24013)

I also saw inconsistent things on other ranges. Just posted this one as example to report a possible bug.

Maybe the problem has something to do with 87000119 which I trial factored to 70bit 2 days ago. I think this one still counts to the assigned TFs.

[garo]

George has said before that the server scripts that calculate these numbers can be buggy because exponents may move around columns while the numbers are being computed. That being said I have seen consistent errors of "off by one or two" for as long as I can remember.

[cheesehead]

Originally Posted by garo

George has said before that the server scripts that calculate these numbers can be buggy because exponents may move around columns while the numbers are being computed.

Oh, yeah -- the report-generator doesn't (can't afford to!) lock the database against changes while it's doing its totaling. There could be a mechanism for segregating new changes for a while as the report generator works (in effect, fixing a database image as of a certain time, when the report started, until it was finished), but that's obviously not being done here.