# Re: Fuzzy Time (#99) **URL:** \ **Category:** Ruby\ **Created:** [October 27, 2006, 6:01pm UTC](https://www.ruby-forum.com/t/re-fuzzy-time-99/73865 "2006-10-27T18:01:56Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![phrogz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/2acd7d/32.png) [@phrogz](https://www.ruby-forum.com/u/phrogz)\ **Post date:** [October 27, 2006, 6:01pm UTC](https://www.ruby-forum.com/t/re-fuzzy-time-99/73865/1 "2006-10-27T18:01:56Z")
From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] > > 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. 🙂 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. 🙂 ---
**Author:** ![phrogz](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/2acd7d/32.png) [@phrogz](https://www.ruby-forum.com/u/phrogz)\ **Post date:** [October 27, 2006, 6:34pm UTC](https://www.ruby-forum.com/t/re-fuzzy-time-99/73865/2 "2006-10-27T18:34:01Z")
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. 😉 > It is. Time flies when you’re coding Ruby, and stands still when you’re > doing work. 🙂 no argument there! > 🙂 > 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