Re: Fuzzy Time (#99)

Ruby
1

From: [email protected] [mailto:[email protected]]

Requirement #2: The time shown by the clock must randomly
vary +/- 5 minutes from reality. For example, if the time
is actually 10:37, the program might output “10:3~” or
“10:4~” (but not “10:2~” or “10:5~”).

Requirement #3: The time on the clock should continuously
increase. If the time shows “10:4~” it must continue to
show “10:4~” until it shows “10:5~”. (It can’t show
“10:4~”, then “10:3~” for a bit and then come back to
“10:4~”.)

it seems like #2 and #3 contradict one another. imagine it’s
10:45 and, through randomness, you choose to vary the clock
by +5, therefore displaying 10:5~, you will not be able to
change the output again until 10:55, and then only because
the upper bould will have rolled over into the next hour.
here it is in table form

That’s correct; why do you call this a contradiction?

The observer has no knowledge that you happened to be a full 5 minutes
ahead of schedule. Internally, your model might be:

Actual Internal Displayed
10:44 10:47 10:4~
10:45 10:50 10:5~
10:46 10:50 10:5~
10:47 10:51 10:5~
10:48 10:52 10:5~
10:49 10:52 10:5~
10:50 10:52 10:5~
10:51 10:52 10:5~
10:52 10:52 10:5~
10:53 10:52 10:5~
10:54 10:52 10:5~
10:55 10:54 10:5~
10:56 10:55 10:5~
10:57 11:00 11:0~

To be clear, by “+/- 5 minutes” I meant “it is not tied to the current
time, but must not deviate by more than 5 minutes from reality”, not “It
must be exactly either 5 minutes ahead or 5 minutes behind the actual
time.”

so the combined effect means that it’s acceptable to display
the same time~
for twenty straight minutes - is that really the a desired
potential effect?

It is. Time flies when you’re coding Ruby, and stands still when you’re
doing work. :slight_smile:

Think about it this way:

In order to not know what time it really is, you cannot always display
the tens digit for exactly 10 minutes in a row. (If you did, the user
would simply have a precise-but-inaccurate clock that was a little fast
or slow.) Thus, you have to be able to sometimes show the tens for less
than ten minutes, and sometimes for greater than ten minutes.

It seemed odd to me that varying by only +/- 5 minutes allows the same
tens digit to be displayed for 20 minutes, but that’s the way the math
comes out. :slight_smile:

2

On Sat, 28 Oct 2006, Gavin K. wrote:

That’s correct; why do you call this a contradiction?

To be clear, by “+/- 5 minutes” I meant “it is not tied to the current time,
but must not deviate by more than 5 minutes from reality”, not “It must be
exactly either 5 minutes ahead or 5 minutes behind the actual time.”

right. i understood that. but this is where i see the contradiction:
from
the viewpoint of the observer a clock which remains static for 20
minutes
cannot also simoutaneously vary a mere 5 minutes from reality. :wink:

It is. Time flies when you’re coding Ruby, and stands still when you’re
doing work. :slight_smile:

no argument there!

:slight_smile:
yes, i see that. still, it seems flawed. think about it on a number
line,
which does not wrap as times do.

so, imagine the time is ‘5’ and our range is ‘+/-5’, and we select ‘10’.
because we must monotonically increase we have to wait till ‘10’ to make
another choice. this time, however, our range will only be ‘+5’,
because we
cannot decrease. let’s say we select +1: ‘11’. when ‘11’ comes our
range
will now still be only ‘+5’, let’s say we max it out again, selecting
‘+5’,
and thus ‘16’… you see, the way #2 and #3 work together a selection
forever
eats the range of subsequent selections - so a the ‘+/-5’ bit becomes no
longer true for any selection > than the current time. the only reason
this
works it’s self out on the clock is that times wrap.

i realize that ‘+5’ is still within ‘+/-5’, but i just wondered if this
was
the intended effect.

great quiz btw!

-a