Re: Mersenne: Re: screen savers
I was just thinking that screen savers perform 2 functions; 1. The flashy display and 2. Locking the keyboard with a pw. The second is more important and must be included otherwise it will not be able to be used instead of the system lock. Cheers... Russ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: screen savers
At 05:56 PM 2/9/2001 EST, [EMAIL PROTECTED] wrote: >Just my 2 cents' worth with respect to the screen saver >proposals: how about the following? > >2) For the folks who like something that looks more >scientific, we could have a vertical box that looks >like a control panel. Every iteration, the bottom Y >bits of the LL residue get printed to the bottom line >of the panel, and the others move up. We could colorize >the individual digits of the hex residues, or pick a >new color for each new Residue, so things look a bit >more dynamic. The faster the user's machine, the more >dynamic the output. I had been thinking that it would be interesting to map the entire savefile, one byte per pixel, into a rectangular area centered on the screen, updating every time a new intermediate savefile is saved. I think default is every 30 minutes, but that can be adjusted. Below the graphic could be displayed the iteration number and exponent. A historical bar graph of iterations throughput per minute, scaled relative to the maximum ever achieved on that machine, for the current runlength, is another. It has the advantageous property that some end users might be encouraged to maximize their throughput via the easy feedback. Make a change, wait, check the graph. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: screen savers
At 08:14 PM 2/9/2001 -0500, Nathan Russell wrote: > The thing here is that this would make the rate of progress slow. I >know that when I first started GIMPS, I got a little depresseed >thinking things like "I've been here an hour and it's not even a third >of a percent done!" When I joined, I was getting a LL test in about 9 hours on my P-60. Now it takes 3 months on my P-300. +---+ | Jud McCranie | | | | Think recursively( Think recursively( Think recursively)) | +---+ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: screen savers
On Fri, 09 Feb 2001 17:56:26 EST, you wrote: >Just my 2 cents' worth with respect to the screen saver >proposals: how about the following? > >1) (This is along the lines of the popular "swarm of >bees" screensaver) Have some bee (or other - perhaps >allow the user to choose from a menu) icons move around >the user's computer screen according to simple dynamical >rules, e.g. allowing them to avoid collisions and >treating the window edges as either reflecting or >periodic boundaries. Every time an LL iteration >completes, use the bottom X ( X is a small integer ) >bits of the interim LL residue, treated as a signed >quantity, to set the x-acceleration of widget #1, and >the next X bits for the y-acceleration. Widget #2 would >similarly use the next 2X bits, etc. We use the bits to >set the acceleration rather than the speed to keep the >movements from being too herky-jerky. We'd need to make >sure the computations involved are sufficiently simple >so as not to steal too much runtime from the actual LL >test. My hunch is that this wouldn't steal much time if the bees move by jumping rather than sliding. >We could also combine the above with some way of >tracking the progress of the current assignment. For >instance, if the number being tested is 2^p - 1 and the >user's screen has N pixels, then on average every p/n >iterations, block one more pixel of the imaginary bee >box, say in inward-spiraling fashion. As the test >proceeds, the walls of the box slowly close in. >(Admittedly, not a good screen saver for the >claustrophobic :) The thing here is that this would make the rate of progress slow. I know that when I first started GIMPS, I got a little depresseed thinking things like "I've been here an hour and it's not even a third of a percent done!" There are possible ways to make it appear that work is being done quickly- the Tower of Hanoi comes to mind, though we would need to make double moves on some iterations, since runtimes can only be a power of two steps. Perhaps there could be an option to play a fanfare or some such every time one of the six or seven bottom discs in the tower is moved. >2) For the folks who like something that looks more >scientific, we could have a vertical box that looks >like a control panel. Every iteration, the bottom Y >bits of the LL residue get printed to the bottom line >of the panel, and the others move up. We could colorize >the individual digits of the hex residues, or pick a >new color for each new Residue, so things look a bit >more dynamic. The faster the user's machine, the more >dynamic the output. That's also a fairly interesting idea. Maybe the colorization could vary with the current iteration number in some fashion - for example, we could have the lines of text each broken into blocks of rainbow color, with each column of blocks shifting according to the base 7 number of the current iteration - it would start partway through, according to how far below the next highest power of 7 the exponent was. Then, as the run continued, the right-hand word in each line would shift by one color for each iteration, wrapping around - when the bottom line was solid violet, you'd be done. Nathan _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: screen savers
Just my 2 cents' worth with respect to the screen saver proposals: how about the following? 1) (This is along the lines of the popular "swarm of bees" screensaver) Have some bee (or other - perhaps allow the user to choose from a menu) icons move around the user's computer screen according to simple dynamical rules, e.g. allowing them to avoid collisions and treating the window edges as either reflecting or periodic boundaries. Every time an LL iteration completes, use the bottom X ( X is a small integer ) bits of the interim LL residue, treated as a signed quantity, to set the x-acceleration of widget #1, and the next X bits for the y-acceleration. Widget #2 would similarly use the next 2X bits, etc. We use the bits to set the acceleration rather than the speed to keep the movements from being too herky-jerky. We'd need to make sure the computations involved are sufficiently simple so as not to steal too much runtime from the actual LL test. We could also combine the above with some way of tracking the progress of the current assignment. For instance, if the number being tested is 2^p - 1 and the user's screen has N pixels, then on average every p/n iterations, block one more pixel of the imaginary bee box, say in inward-spiraling fashion. As the test proceeds, the walls of the box slowly close in. (Admittedly, not a good screen saver for the claustrophobic :) 2) For the folks who like something that looks more scientific, we could have a vertical box that looks like a control panel. Every iteration, the bottom Y bits of the LL residue get printed to the bottom line of the panel, and the others move up. We could colorize the individual digits of the hex residues, or pick a new color for each new Residue, so things look a bit more dynamic. The faster the user's machine, the more dynamic the output. -Ernst _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers