in reply to Re: Compare two dates
in thread Compare two dates

These are ISO 3 date formats.

Are you sure? Wikipedia seems to think this standard deals with something called a Renard series. (Update: Also here if you have some money burning a hole in your pocket and you just gotta know.)

Give a man a fish:  <%-{-{-{-<

Replies are listed 'Best First'.
Re^3: Compare two dates
by afoken (Chancellor) on Jul 24, 2019 at 20:04 UTC

    ISO 8601 uses the YYYY-MM-DD format.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
Re^3: Compare two dates - what's Renard Series?
by bliako (Abbot) on Jul 24, 2019 at 23:12 UTC

    damned I am! I have been trying to find out what Renard Series is for some time now (edit: after I read about it for the first time just today, above), but all I could get was stereotypes copy-pasted from site to site and online encyclopaedia to o.e. Can anyone please explain in plain language what Renard Series and what Prefered Numbers are? I thought my life was complete but Renard Series set me back. Is this the engineering-clan equivalent of the "secret handshake"? Extra bonus for not looking it up on the net - I had enough of that.

    bw, bliako

[reply]
      what Prefered Numbers are
      Illustration with an example for programmers: you wish to show result list entries and provide a drop-down that selects the number of displayed items per page. What values do you put there?

      The number system in common use is base 10, so we likely want to have 10, 100, 1000 in there. That's not fine-grained enough for practical use in most cases. Let's make it evenly spaced in between each magnitude and explore for seven and three steps, each. 

      › $a = 10
10
› sprintf '%.f', $a += (100-10)/7
23
› sprintf '%.f', $a += (100-10)/7
36
› sprintf '%.f', $a += (100-10)/7
49
› sprintf '%.f', $a += (100-10)/7
61
› sprintf '%.f', $a += (100-10)/7
74
› sprintf '%.f', $a += (100-10)/7
87
› sprintf '%.f', $a += (100-10)/7
100

› $a = 10
10
› sprintf '%.f', $a += (100-10)/3
40
› sprintf '%.f', $a += (100-10)/3
70
› sprintf '%.f', $a += (100-10)/3
100

      [download]
      That does not feel good for the seven scale. There is no meaningful difference between 74 and 87, when confronted with that choice, a user might pick either one by random chance. That's because humans instinctively operate on a scale that is lopsided with increasingly larger steps towards the "heavy" end: the geometric progression. It's still evenly spaced, just not additively, but multiplicatively. From observing nature, we also know that's much more common. Trying it out: 
      › $a = 10
10
› sprintf '%.f', $a *= 10**(1/7)
14
› sprintf '%.f', $a *= 10**(1/7)
19
› sprintf '%.f', $a *= 10**(1/7)
27
› sprintf '%.f', $a *= 10**(1/7)
37
› sprintf '%.f', $a *= 10**(1/7)
52
› sprintf '%.f', $a *= 10**(1/7)
72
› sprintf '%.f', $a *= 10**(1/7)
100

› $a = 10
10
› sprintf '%.f', $a *= 10**(1/3)
22
› sprintf '%.f', $a *= 10**(1/3)
46
› sprintf '%.f', $a *= 10**(1/3)
100

      [download]
      That feels better. On the seven scale, the initial values are too tight, that's because we have so many steps, let's discard this scale. For the remaining scale, rouding the numbers (to most significant digit), we get preferred numbers, expressed as the series: 10, 20, 50, 100, 200, 500, 1000, …. Let's put those in the drop-down. 
      # playground
my ($start, $end) = (10, 100);  # try: (35, 7400)
for my $step (1..20) {
    printf 'step %2d:', $step;
    my $i = $start;
    for (1..$step+1) {
        printf ' %.f', $i;
        $i *= ($end/$start)**(1/$step);
    }
    print "\n";
}
__END__
step  1: 10 100
step  2: 10 32 100
step  3: 10 22 46 100
step  4: 10 18 32 56 100
step  5: 10 16 25 40 63 100
step  6: 10 15 22 32 46 68 100
step  7: 10 14 19 27 37 52 72 100
step  8: 10 13 18 24 32 42 56 75 100
step  9: 10 13 17 22 28 36 46 60 77 100
step 10: 10 13 16 20 25 32 40 50 63 79 100
step 11: 10 12 15 19 23 28 35 43 53 66 81 100
step 12: 10 12 15 18 22 26 32 38 46 56 68 83 100
step 13: 10 12 14 17 20 24 29 35 41 49 59 70 84 100
step 14: 10 12 14 16 19 23 27 32 37 44 52 61 72 85 100
step 15: 10 12 14 16 18 22 25 29 34 40 46 54 63 74 86 100
step 16: 10 12 13 15 18 21 24 27 32 37 42 49 56 65 75 87 100
step 17: 10 11 13 15 17 20 23 26 30 34 39 44 51 58 67 76 87 100
step 18: 10 11 13 15 17 19 22 24 28 32 36 41 46 53 60 68 77 88 100
step 19: 10 11 13 14 16 18 21 23 26 30 34 38 43 48 55 62 70 78 89 100
step 20: 10 11 13 14 16 18 20 22 25 28 32 35 40 45 50 56 63 71 79 89 1
+00

      [download]
      Also see – division of European money: 0.01, 0.02, 0.05, 0.10, 0.20, 0.50, 1, 2, 5, 10, 20, 50, 100… Pity the fools who have to deal with 0.25 units with no corresponding 2.5 and 25.
[reply]
[d/l]
[select]

        that's super thanks.

        Your last comment about money denominations got me thinking: another aspect of these numbers is to be able to construct sums with the shortest linear combination - e.g. use the fewest different money denominations for change of 39.43. So that's an added optimisation parameter right? Is there theory for that?

[reply]
[reply]
[d/l]

        i get it!

[reply]

      I know you've said you better understand it now... but there was a small point that I like, that I don't think was brought out enough. Like AnomalousMonk's link to resistor tolerances implies (but doesn't say explicitly enough, IMO): one of the nice things about the series is that it keeps allowable tolerance consistent. If you're manufacturing widgets, and your manufacturing has 0.1mm tolerance, then doing widgets in sizes 1,2,3,4,5,6,7,8,9,10 is reasonable; none of the widget sizes will overlap. But if you manufacture with 10% tolerance, then the step from 1 to 2 is fine, because 1+10%=1.1 doesn't overlap with 2-10%=1.8. But at the step from 9 to 10, 9+10%=9.9 and 10-10%=9, so a value of 9 is a technically valid 9+-10% or 10+/-10% widget. If you count the "maximum allowable tolerance" as the point where the lower value shifted up by the tolerance and the upper value shifted down by the tolerance are equals, then you can see:

      #!/usr/bin/env perl
# Preferred Numbers: https://perlmonks.org/?node_id=11103336

my $prev = 1;
for my $this ( 2 .. 10 ) {
    # an x% change can fit between $prev and $this
    # x% changes, depending on $this
    # Overlap will start if x% is such that prev * (1+x%) == this * (1
+-x%)
    #   algebra:
    #       p*(1+x) = t*(1-x)
    #       p + px = t - tx
    #       (p+t)x = t-p
    #       x = (t-p)/(p+t)
    #       x% = 100%*x
    my $xpct = ($this-$prev) / ($this+$prev) * 100;
    printf "linear: %.2f .. %.2f => %.2f%%\n", $prev, $this, $xpct;
} continue {
    $prev = $this;
}

print "\n";

my $prev = 1;
for my $i ( 1 .. 10 ) {
    # now go in 10 logarithmic steps
    $this = $prev * (10**(1/10));
    my $xpct = ($this-$prev) / ($this+$prev) * 100;
    printf "logarithmic: %.2f .. %.2f => %.2f%%\n", $prev, $this, $xpc
+t;
} continue {
    $prev = $this;
}

print "\n";

my $prev = 1;
for my $i ( 1 .. 10 ) {
    # now go in 10 logarithmic steps
    $this = 10**($i/10);
    my $round_p = int($prev*10+0.5)/10;
    my $round_t = int($this*10+0.5)/10;
    my $xpct = ($round_t-$round_p) / ($round_t+$round_p) * 100;
    printf "rounded logarithmic: %.2f .. %.2f => %.2f%%\n", $round_p, 
+$round_t, $xpct;
} continue {
    $prev = $this;
}

__END__
linear: 1.00 .. 2.00 => 33.33%
linear: 2.00 .. 3.00 => 20.00%
linear: 3.00 .. 4.00 => 14.29%
linear: 4.00 .. 5.00 => 11.11%
linear: 5.00 .. 6.00 => 9.09%
linear: 6.00 .. 7.00 => 7.69%
linear: 7.00 .. 8.00 => 6.67%
linear: 8.00 .. 9.00 => 5.88%
linear: 9.00 .. 10.00 => 5.26%

logarithmic: 1.00 .. 1.26 => 11.46%
logarithmic: 1.26 .. 1.58 => 11.46%
logarithmic: 1.58 .. 2.00 => 11.46%
logarithmic: 2.00 .. 2.51 => 11.46%
logarithmic: 2.51 .. 3.16 => 11.46%
logarithmic: 3.16 .. 3.98 => 11.46%
logarithmic: 3.98 .. 5.01 => 11.46%
logarithmic: 5.01 .. 6.31 => 11.46%
logarithmic: 6.31 .. 7.94 => 11.46%
logarithmic: 7.94 .. 10.00 => 11.46%

rounded logarithmic: 1.00 .. 1.30 => 13.04%
rounded logarithmic: 1.30 .. 1.60 => 10.34%
rounded logarithmic: 1.60 .. 2.00 => 11.11%
rounded logarithmic: 2.00 .. 2.50 => 11.11%
rounded logarithmic: 2.50 .. 3.20 => 12.28%
rounded logarithmic: 3.20 .. 4.00 => 11.11%
rounded logarithmic: 4.00 .. 5.00 => 11.11%
rounded logarithmic: 5.00 .. 6.30 => 11.50%
rounded logarithmic: 6.30 .. 7.90 => 11.27%
rounded logarithmic: 7.90 .. 10.00 => 11.73%

      [download]

      The linear scale wastes a lot of the tolerance near the low end, so you can have 30%, but at the high end, you can really only have 5% tolerance on the widgets. However, if you're doing 5% widgets, at the low end, you'll have big gaps, and a customer will complain that they want an intermediate value. With the even-logarithmic steps, every step between sizes will have the same amount of "room" for the tolerances, so if you can manufacture the widgets with 10% tolerance, they'll all nicely fit, with no overlap between sizes. (Even with some rounding on the Preferred Numbers in the 10-logarithmic steps will still show about the same tolerance range, and can handle 10% tolerance just fine.)

[reply]
[d/l]

        I am interested in manufacturing, from the point of centrally planning an economy. Albeit, I had no practical exposure to it ever and so all this stuff and your explanation is interesting and helpful.

        Wouldn't increasing tolerances just for the sake of not overlapping, going to be a headache for users? Is this "best practice" in design? I mean I buy 2 screws and the bigger one has double (percentage-wise) tolerance than that of the smaller one!

[reply]

In Section Seekers of Perl Wisdom