Features request?

[James Heinrich]

I lived in Kelowna for a year so I'm not unfamiliar with the area

[chalsall]

Originally Posted by chalsall

What can I say? They do chemistry better there.... ()

Just to tangent back here and rant for a bit if I may...

So, our contractor finally shows up to do the last of the snagging (just) before we pour the concrete tomorrow.

He announces that we need more concrete, and more Xypex Additive and Zypex Concentrate (two separate products).

Wanting to confirm this (Zypex is /very/ expensive) Linda calls the local supplier to ask what the proper mix ratio is. The answer was "Oh, three pet (soda drink) bottles cut off to the top of the label full per bag of cement.

A new measurement standard I had never heard of before!

Sigh....

[petrw1]

Could we get another level or 2 of zoom in?

[James Heinrich]

Originally Posted by petrw1

Could we get another level or 2 of zoom in?

No?

In all seriousness, it can be done, but at the expense (much) increased data storage requirements and somewhat increased time to generate the data each day. More explicitly, at the 1M level I track about 16k data points per day, and the query takes ~2.5 minutes. At 10k resolution that increases to 900k data points and a 30-minute query. I can probably optimize the query a bit, but 900k data points per day is... a lot. Mind you that's across the full M2³² range, not the 1000M PrimeNet range.

I'm rerunning the query now to see how many datapoints I come up with for 100k resolution, which might be a feasible compromise.
edit: answer: about 100k, which is still a pile, but not completely impractical.

[Prime95]

Originally Posted by James Heinrich

it can be done, but at the expense (much) increased data storage requirements

There is another option. At fine granularity run the query on the Primenet server. The server should be able to sum up small intervals without too much server load. Historical data though would be very hard or impossible to calculate.

[James Heinrich]

A more complex compromise I haven't properly thought through could be something like 0.01M resolution in (0M-100M); 0.1M resolution in (100M-1000M); 1M resolution in (1000M-4294M). This would give the most detail where people are likely to care without too many spurious data points.

Running a quick test, that works out to 75k data points and a not-unreasonable ~3-minute query

[petrw1]

Originally Posted by James Heinrich

A more complex compromise I haven't properly thought through could be something like 0.01M resolution in (0M-100M); 0.1M resolution in (100M-1000M); 1M resolution in (1000M-4294M). This would give the most detail where people are likely to care without too many spurious data points.

Running a quick test, that works out to 75k data points and a not-unreasonable ~3-minute query

Sounds reasonable...

[snme2pm1]

Originally Posted by James Heinrich

Please give more details as to which numbers you saw as incorrect (and what you think they should be, and where you got the correct number from).

As an example, the unfactored 5M region has been fully explored out 65 bits, http://www.mersenne.org/report_facto...o=1&bits_hi=64.
However, http://www.mersenne.ca/status/tf/0/3/0# shows 375 below 65 bits.
Is it perhaps including factored exponents in the tally?
By the way, the links on those rows have broken, all saying onClick="location = 'http://www.mersenne.org/report_factoring_effort/?exp_lo=0000000&exp_hi=0999999';"
Similarly: the 4M region has been explored out 66 bits, but the preview report shows 942 at only 65 depth.

[manfred4]

Another thing since this has gotten your "new visualization tool"-thread: This Picture seems to not be updating properly anymore since 6 days, the progress in the last 6 days seems to be way too less compared to the timeintervals before. Did you mess around there as well?

[snme2pm1]

Originally Posted by snme2pm1

Similarly: the 4M region has been explored out 66 bits, but the preview report shows 942 at only 65 depth.

Further probing of mersenne.org suggests that the 66 bit column figure for 4M should be 21629, which is 942+20687, i.e. some of the tally has been splintered into the preceding bucket.
p.s. Later columns look correct.

[James Heinrich]

Originally Posted by James Heinrich

I'll wait until it's finished chewing on the unprocessed known factors before I take a closer look, although a quick glance suggests that alone is not sufficient to explain the difference.

Update: this list is now down to about 525000 factors to check and absorb. Another couple days.

Originally Posted by James Heinrich

... I can get a 1-time export of all unfactored PrimeNet exponents and their TF level to bring my master table in sync with PrimeNet

George has just provided me with the data I need on this front, importing it now. As suspected above, there's a significant number of discrepancies in the 500M range and elsewhere. Broken down more, these are the ranges and counts that were off in my data:

    [000] => 490
    [001] => 1711
    [002] => 9164
    [003] => 5145
    [005] => 230
    [007] => 13707
    [008] => 9998
    [009] => 4733
    [010] => 5063
    [011] => 443
    [201] => 1
    [219] => 1
    [232] => 1
    [300] => 1
    [387] => 1
    [428] => 1
    [439] => 3
    [456] => 3
    [528] => 231
    [532] => 22
    [533] => 128
    [536] => 78
    [537] => 2
    [541] => 241
    [576] => 4577
    [577] => 21983
    [578] => 20578
    [579] => 21684
    [580] => 8846
    [581] => 10122
    [582] => 18635
    [583] => 13978
    [584] => 14295
    [585] => 21140
    [586] => 22344
    [587] => 16286
    [588] => 10010
    [589] => 19486
    [946] => 12850