I lived in Kelowna for a [url=https://en.wikipedia.org/wiki/2003_Okanagan_Mountain_Park_Fire]year[/url] so I'm not unfamiliar with the area :smile:

[QUOTE=chalsall;408264]What can I say? They do chemistry better there.... (:wink:)[/QUOTE]

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....

I'm liking it so far....
 

Could we get another level or 2 of zoom in?

[QUOTE=petrw1;408425]Could we get another level or 2 of zoom in?[/QUOTE]No? :whistle:

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[sup]32[/sup] 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.

[QUOTE=James Heinrich;408429]it can be done, but at the expense (much) increased data storage requirements [/QUOTE]

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.

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

[QUOTE=James Heinrich;408433]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[/QUOTE]

Sounds reasonable...

[QUOTE=James Heinrich;408376]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).
[/QUOTE]

As an example, the unfactored 5M region has been fully explored out 65 bits, [url]http://www.mersenne.org/report_factoring_effort/?exp_lo=5000000&exp_hi=5999999&bits_lo=1&bits_hi=64[/url].
However, [url]http://www.mersenne.ca/status/tf/0/3/0#[/url] 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.

Another thing since this has gotten your "new visualization tool"-thread: [URL="http://www.mersenne.ca/graphs/factor_bits_384M/factor_bits_384M_20150820.png"]This Picture[/URL] 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?

[QUOTE=snme2pm1;408435]Similarly: the 4M region has been explored out 66 bits, but the preview report shows 942 at only 65 depth.[/QUOTE]

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.

[QUOTE=James Heinrich;408386]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.[/quote]Update: this list is now down to about 525000 factors to check and absorb. Another couple days.

[QUOTE=James Heinrich;408386]... 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[/QUOTE]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:[code] [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[/code]