Future requests?
 

I see we don't have a thread for requesting new features :razz:

Well... my request is not exactly about GPU-2-72, but about the visualization page. When we go to the[URL="http://www.mersenne.info/trial_factored_tabular_data/0/0/"] max zoom out on the table[/URL], there is a lot of information lost on the right, because the smaller expos (under 14M) are factored not too high, and they have to be on the table. This is valid not only for the status (tabular) view, but for [URL="http://www.mersenne.info/trial_factored_tabular_delta_7/0/0/"]changes table[/URL] too. And it may affect lower levels of zoom too.

So, my suggestion would be to implement either a possibility to "move" left-right with the columns (pan, or select from-to bits), or either implement a larger table (that would go out of screen, but then use firefox's "pan" functions), or either have a checkbox on that page, to "ignore first 10M exponents", or better 15M, 20M, or either to have an "intermediary" zoom level which ignores first row. I keep in mind that the things on the upper ranges of exponents are still evolving (lowest bound is raising) and also less and less people are interested on the lower expos which are already "cleared", "factored", etc.

[QUOTE=LaurV;296490]So, my suggestion would be to implement either a possibility to "move" left-right with the columns (pan, or select from-to bits), or either implement a larger table (that would go out of screen, but then use firefox's "pan" functions), or either have a checkbox on that page, to "ignore first 10M exponents", or better 15M, 20M, or either to have an "intermediary" zoom level which ignores first row. I keep in mind that the things on the upper ranges of exponents are still evolving (lowest bound is raising) and also less and less people are interested on the lower expos which are already "cleared", "factored", etc.[/QUOTE]

A reasonable and logical request.

In all honesty, I haven't spent much time with the Mersenne.info site/code for several months. But I should do so.

Let me get back to you.... :smile:

I've been thinking it would nice to be able to select ranges other than those with boundaries/multiples at powers of 10; that is to say, be able to view 36-46M instead of just 30-40M and 40M-50M; that is to say (again) something like what you did with the "Workers's Progress" graphs on GPU272.

Ya know, not cuz you need more work or anything :razz:

[QUOTE=Dubslow;296522]I've been thinking it would nice to be able to select ranges other than those with boundaries/multiples at powers of 10; that is to say, be able to view 36-46M instead of just 30-40M and 40M-50M; that is to say (again) something like what you did with the "Workers's Progress" graphs on GPU272.[/QUOTE]

Yes... That request was also noted, and added to the todo list. It is also reasonable and logical. :smile:

Is it possible to generate a downloadable worktodo.txt file instead of having to cut and paste the individual lines generated on the 'get assignments' page?

[QUOTE=mognuts;296537]Is it possible to generate a downloadable worktodo.txt file instead of having to cut and paste the individual lines generated on the 'get assignments' page?[/QUOTE]

If this was mersenne.facebook I'd be looking for the "Like" button.

[QUOTE=LaurV;296490]When we go to the[URL="http://www.mersenne.info/trial_factored_tabular_data/0/0/"] max zoom out on the table[/URL], there is a lot of information lost on the right, because the smaller expos (under 14M) are factored not too high, and ...[/QUOTE]

gee for a split second I thought you were going to end your above sentence with:

[QUOTE]"so I'm going to GPU them all to 65 bits just so you don't have to bother changing the report."[/QUOTE]

oh well wishful thinking.
:rofl:

[QUOTE=petrw1;296558]gee for a split second I thought you were going to end your above sentence with:

oh well wishful thinking.
:rofl:[/QUOTE]

What is even funnier (or, perhaps, sadder) is I and a few others compiled our own versions of mprime to remove the sanity check, and took the last few hundred low candidates up to 60 bits using CPUs just for the hell of it a couple of years ago.... :smile:

[QUOTE=petrw1;296557][QUOTE=mognuts]Is it possible to generate a downloadable worktodo.txt file instead of having to cut and paste the individual lines generated on the 'get assignments' page?[/QUOTE]If this was mersenne.facebook I'd be looking for the "Like" button.[/QUOTE]

OK... I'm hearing that this is a desired feature... :wink:

Would it be OK if this was a function from the View Assignments page? It would be [U][I]much[/I][/U] easier to implement there.

[QUOTE=petrw1;296558]gee for a split second I thought you were going to end your above sentence with:

Quote:
"so I'm going to GPU them all to 65 bits just so you don't have to bother changing the report."

oh well wishful thinking.
:rofl:[/QUOTE]

[QUOTE=chalsall;296562]What is even funnier (or, perhaps, sadder) is I and a few others compiled our own versions of mprime to remove the sanity check, and took the last few hundred low candidates up to 60 bits using CPUs just for the hell of it a couple of years ago.... :smile:[/QUOTE]

Yeah, I would do it with pleasure! I am the crazy farang who took M1061 from 62 to 63 bits(**see Notes below) and the same guy who P-1 this exponent to those astronomical limits, [URL="http://www.mersenneforum.org/showpost.php?p=279785&postcount=121"]see here[/URL] (it took few months for P-1 with p95). I did it (the TF) with my own (slow multiplication) tool, who checks all 8kp+1 and 8kp+6p+1 numbers (prime or not), for natural k and p=1061, and the 63-to-64 is on the way too, but interrupted at about 15% some time ago. The same slow tool I use it for the stuff in [URL="http://www.mersenneforum.org/showpost.php?p=294009&postcount=1214"]this post[/URL] (trying P-1 on GPU). I would do "lower expos to 64 and higher" with pleasure if I would have a FAST software tool. I HAVE THE HARDWARE! That is why I am "hitting" other forum members in posts like [URL="http://www.mersenneforum.org/showpost.php?p=296501&postcount=1754"]this one[/URL], and keep my eyes on the range.

Notes:
** that job I reported as "mfaktc-faked-by-LaurV", the "faked" part does not refers to the job (the job was done last year!) but it refers to the report itself, as Primenet doesn't know my tool, and I had to report it as mfaktc. And with this opportunity I found out that the formula to compute the credit has a "gap". (read as "has an error, George, are you there?"). Generally the credit doubles with every bit-step for a given exponent, with the exception of exponents lower then 2000, from 62 to 63 bits, where it has a "times 4" jump. So, the credit it gives for a 62-63 bit on M1061 is about ~900GHzDays, but it should be only ~450GD. The credit for 61 to 62 is correctly given as ~230GD, and so far correct for all lower or higher. The "gap" is only 62 to 63 bits. The same error appears in the [URL="http://mersenne-aries.sili.net/credit.php?worktype=TF&exponent=1061&f_exponent=&b1=&b2=&numcurves=&factor=&frombits=62&tobits=63&submitbutton=Calculate"]mersenne-aries page[/URL], I believe James uses the same formulas. This should be a two-days job on a gtx580 with a "good mfaktc" program, but it took me over two weeks.

[QUOTE=LaurV;296593]And with this opportunity I found out that the formula to compute the credit has a "gap". (read as "has an error, George, are you there?"). Generally the credit doubles with every bit-step for a given exponent, with the exception of exponents lower then 2000, from 62 to 63 bits, where it has a "times 4" jump. So, the credit it gives for a 62-63 bit on M1061 is about ~900GHzDays, but it should be only ~450GD. The credit for 61 to 62 is correctly given as ~230GD, and so far correct for all lower or higher. The "gap" is only 62 to 63 bits. The same error appears in the [URL="http://mersenne-aries.sili.net/credit.php?worktype=TF&exponent=1061&f_exponent=&b1=&b2=&numcurves=&factor=&frombits=62&tobits=63&submitbutton=Calculate"]mersenne-aries page[/URL], I believe James uses the same formulas.[/QUOTE]You can call it a "gap" if you like, but it's not an error. It's designed to reflect [url=http://mersenne-aries.sili.net/throughput.php?cpu1=Intel%28R%29+Core%28TM%292+CPU+6300+%40+1.86GHz|2048|0&mhz1=1000]actual CPU TF performance[/url] (example showing theoretical 1GHz Core2 Duo, basis of GHz-days metric) at around the 62-64 transition. If you look at [url=http://mersenne-aries.sili.net/bench.php]CPU TF benchmarks[/url] you'll notice a large jump in TF times around 62-63 bits (11ms -> 17ms in the Core2 example), but you'll also notice the GHz-days/day TF graph stays flatline at 1.0GHz-days/day despite the slowdown. GHz-days are architechture-specific performance and may not make sense in other contexts, such as using mfaktc which doesn't perform the same (but is analogous to the mfakto slowdown above 2^70).

The actual formula for George's code, which is also used on my site, includes this comment:[code]// bits tf_timing
// ---- ---------
// <=62 0.00465
// 63-64 0.00743
// >=65 0.00707[/code]