[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: [QUIZ] Fuzzy Time (#99)
From:       "Paolo Negri" <hungrylist () gmail ! com>
Date:       2006-10-31 19:10:50
Message-ID: b242f69c0610311110v41283f6cl6a73598bdb87f7c4 () mail ! gmail ! com
[Download RAW message or body]

Here's a unit test that does a similar test against my class. It's a
quick and dirty add on to a previous test, so the code may be
confusing. Anyway it collects the data about the difference among the
time shown by to_s method and the actual time in minutes.

To do this 0 digits are hidden so the distance can be calculated.
There's a condition to avoid collecting the distance when the hour is
about to change, so the distance is collected in any moments but not
when the printed time or the actual time are in 54 - 59 minute

This is a sample output

-5 -> 0.19824880224682
-4 -> 3.91069363479739
-3 -> 7.90635104198626
-2 -> 11.1160935545538
-1 -> 13.5352009629228
0 -> 14.8497793302023
1 -> 14.4580019352859
2 -> 13.0572797432206
3 -> 10.5945103962616
4 -> 7.28800358735928
5 -> 3.0858370111633

and another one

-5 -> 1.43872994873491
-4 -> 5.60017954593777
-3 -> 9.32693897800562
-2 -> 12.1252569160623
-1 -> 14.1238866970635
0 -> 14.9412932032413
1 -> 14.0482884074748
2 -> 12.1028136738406
3 -> 9.37891280209785
4 -> 5.53875593564696
5 -> 1.37494389189445

both with 100000 iterations.

results are in general more centerd on the positive part of the
offset, like the first one.
I think the trend to go on the positive side is due to the fact in my
code I'm moving (increasing or decreasing) my offset at a constant
speed of 1 unit per each second, but when this speed is composed with
the natural speed of the time, the overall movement of the time I
display is more fast going in the positive direction.

Basicly I'm walking at 2 secs every seconds when I walk on the
positive direction while I just stop the time when I go down. This
makes positive offsets more easy to reach and more hard to leave,
while the opposite happens for negative offsets. Well, maybe... I'm
not 100% sure :P

Here's the code to run the test

require 'fuzzy_time'
require 'test/unit'
class TestFuzzyTime < Test::Unit::TestCase
  def test_in_range
    @bore_level = 100000
    @ft = FuzzyTime.new(Time.new, :hidden_digits => 0)
    diff_coll = Hash.new(0)
    @bore_level.times do
      previous = @ft.to_s
      @ft.advance(60)
      actual = @ft.actual.strftime('%H%M').to_i
      printed = @ft.to_s.sub(':', '').to_i
      difference = actual - printed
      #puts "actual #{actual} printed #{printed} difference #{difference}"
      unless printed.to_s =~ /\d*5[4-9]/ || actual.to_s =~ /\d*5[4-9]/
        diff_coll[difference] += 1
        raise "actual #{actual.to_s} previous #{printed} difference
#{difference}" if difference > 5
        assert (difference.abs <= 5)
      end
    end
    total = diff_coll.values.inject(0) {|sum, value| sum + value}
    (-5..5).each {|num| puts [num,
(diff_coll[num])*100/total.to_f].join(' -> ')}
  end
end


On 31/10/06, Tom Pollard <tomp@earthlink.net> wrote:
>
> On Oct 31, 2006, at 1:05 AM, Tom Pollard wrote:
> > Here are some comparisons of the three update methods, tested by
> > running 100000 60-second 'advances' with each method. The numbers
> > represent the percentage of the time that each error was found.
> > (The 'error', again, is the reported time minus the actual time, in
> > minutes.)
>
> Out of curiosity, I tried translating Cameron's method into my code.
> (This mainly involved working in units of minutes, rather than
> seconds).   I found it produces the following distribution,
>
> Cameron's method
> * Choose offset uniformly from the set [-5..1], , but don't change
> the reported time if the chosen offset would cause it to retrogress.
> -5   -4   -3   -2   -1    0    1    2    3    4    5
> 0.0  1.2  7.2 18.1 28.4 28.3 16.7  0.0  0.0  0.0  0.0
>
> The results are reasonably balanced, centered more-or-less
> symmetrically around minus a half-minute.
> Also, in this scheme, the reported time can /never/ be more than one
> minute ahead of the actual time.
>
> I wanted to do this with other people's entries, too, but am out of
> time for now...
>
> Cheers,
>
> Tom
>
> > Method 1
> > * Choose offset uniformly from the set of values that prevent the
> > reported time from regressing.
> >
> > -5   -4   -3   -2   -1    0    1    2    3    4    5
> > 0.0  0.0  0.0  0.0  0.1  0.3  1.6  6.2 18.4 36.5 36.9
> >
> > Method 2
> > * Choose offset uniformly from the set of all allowable offsets,
> > but don't change the reported time if the chosen offset would cause
> > it to retrogress.
> >
> > -5   -4   -3   -2   -1    0    1    2    3    4    5
> > 0.0  0.1  0.7  2.2  5.5 10.2 15.7 19.7 20.3 16.6  9.0
> >
> > Method 3
> > * Changes offset randomly by +/- one minute on each update, but
> > don't change the reported time if the chosen offset would cause it
> > to retrogress.
> >
> > -5   -4   -3   -2   -1    0    1    2    3    4    5
> > 9.2  9.4  9.6  9.3  9.1  8.8  9.1  9.0  8.8  8.8  9.0
> >
>
>
>

[prev in list] [next in list] [prev in thread] [next in thread]