I can see how one might arrive at a correlation though. The more
important the data, the more I generally type. The more I type, the more
keystrokes. The more keystrokes, the more likely I am to hit that random
number.
It is all starting to fall together for me. Thanks.
Dennis Brown wrote:
Jim,
You need to tell your friend that that's ridiculous. These programs
can't tell which data is important or when your deadline is. It is all
zeros and ones. Nope, it is just a simple calculation. The user
provides the correlation inadvertently. If the data is important, the
user will suffer more when it goes bye bye. If the deadline is
looming, the user will be so engrosed in completing it on time, that
they will forget to save periodically. That is why it is so important
to wipe that ability to concentrate completely on a task to the
exclusion of all else from the gene pool.
TIC
Dennis
On Mar 25, 2006, at 4:13 PM, Jim Ault wrote:
Thanks for clearing up part of the mystery for me.. I thought it was
some
sort of cubic spline and the volume under that surface. Glad to know
it is
only a random number.
One of my friends still believes it is an inverse proportion to the
importance of the data and the minutes until the deadline...
freq = importance/time = maximizing relative loss
Jim Ault
Las Vegas
On 3/25/06 12:32 PM, "Dennis Brown" <[EMAIL PROTECTED]> wrote:
After a lot of clever hacking, I have found that I can almost always
find the counter in any application that counts the number of
keystrokes since the last save. Once the counter crosses a certain
threshold, a random number is invoked in each new keystroke. If the
random number matches the keystroke count, then a crash is provoked.
It is all part of a secret programmers guild directive designed to
help users learn to save and back up their work regularly. It is
expected that after 11 generations, the urge to save will become a
reflex built into the human genome through natural selection. Those
who do not learn to save will become failures in life --unable to
attract a mate. Their "bad" genes will then vanish from the species.
Dennis ;-)
On Mar 24, 2006, at 11:49 AM, Jon Seymour wrote:
Hi, I've been using Rev for about a year. I'm sure it won't shock
most of you to hear that periodically Rev just seems tired and
crashes. Now I am sure that coding glitches are sometimes at fault,
but generally speaking I think Rev (esp. 2.7) has stability issues.
Here's the thing, though: it seems that if I am saving the stack
periodically, which I would tend to do to avoid losing data in a
crash, the program actually crashes less. It's as if saving has
some benefit to memory management or who-knows-what-else in the
engine. It's like a "refresh" function. Has anyone else observed
this? Is there a rationale? Would it be smart to have a commercial
application save its stacks regularly, not only to store user
changes, but simply to confer stability?
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
