o
    o       o

 o             o

h               o

 o             o

    m       o
        o
[download]

        o
    o       x

 o             o

o               o

 o             o

    o       o
        o
[download]

        0
   11       1

10             2

9               3

 8             4

    7       5
        6
[download]

        1
    0       2

 0             2

0               2

 0             2

    0       1
        0
[download]

for my $i ( map {$_,11-$_} 0..5 ) {
   $x = ($i<6)+($i&&$i<5);
   printf "%2d: %d\n", $i, 0+$x;
}
[download]

 0: 1
11: 0
 1: 2
10: 0
 2: 2
 9: 0
 3: 2
 8: 0
 4: 2
 7: 0
 5: 1
 6: 0
[download]

12345678901234567
($i<6)+($i&&$i<5)
--$|+($i&&$i<5)
--$|+($i<5)-!$i
[download]

123456789012345678
substr 122221,$i,1
(1,2,2,2,2,1)[$i]
(1,(2)x4,1)[$i]
vec'XX',$i,2
[download]

Sub-problem 2: The Dreaded Ordering

To analyze this sub-problem as a separate, standalone golf, run the following test program:

for ( 0..11 ) {
   printf "%2d: %2d\n", $_, 0+$x;
   $x = 11-$x+$_%2;
}
[download]

producing:

 0:  0
 1: 11
 2:  1
 3: 10
 4:  2
 5:  9
 6:  3
 7:  8
 8:  4
 9:  7
10:  5
11:  6
[download]

which matches the dreaded ordering. Notice that this formula exploits that an uninitialized Perl variable, namely $x above, starts out with an empty value (undef).

As before, we can replace $_%2 with the $|-- magical flip-flop to produce an alternative 10-stroker:

1234567890
11-$x+$_%2
11-$x+$|--
[download]

I can't find anything shorter though. Can you?

Formula versus lookup table is an over-simplification in that sometimes you can generate a sequence. For example, the map below:

12345678901234567
map{$_,11-$_}0..5
[download]

generates the dreaded ordering. Though longer, this sequence generation is still competitive in this game because it allows other shortenings elsewhere in a complete solution, as we shall see later.

What about a lookup table? Unfortunately, we need four bits, rather than just two for the trailing newline vec encoding of the previous section, because the dreaded ordering values have a wider range, 0..11. So a vec lookup table solution for the dreaded ordering looks like this:

1234567890123456
vec'XXXXXX',$i,4
[download]

where XXXXXX is a string with ord values 176, 161, 146, 131, 116, 101 ... which is six strokes longer than the formula.

So this time the formula defeats the lookup string. One all.

Sub-problem 3: Leading Spaces

The on-the-fly leading space sequence of 8, 4, 7, 1, 13, 0, 15, 1, 13, 4, 7, 8 as in:

        8
    4       7

 1            13

0              15

 1            13

    4       7
        8
[download]

is all over the shop. So much so that I couldn't even begin to contemplate a short formula to produce it.

As before though, a vec lookup string can do it easily because, luckily, all the leading space values happen to be less than 16 and so (just) fit into four bits. That is, running:

for my $i ( map {$_,11-$_} 0..5 ) {
   $x = vec'XXXXXX',$i,4;
   printf "%2d: %2d\n", $i, 0+$x;
}
[download]

where XXXXXX is a string with ord values 120, 253, 125, 72, 1, 65 produces:

 0:  8
11:  4
 1:  7
10:  1
 2: 13
 9:  0
 3: 15
 8:  1
 4: 13
 7:  4
 5:  7
 6:  8
[download]

Notice that the lookup string solutions to all three sub-problems use a very similar vec construction, so it may be possible to combine them in the full solution. Golfers should always be on the lookout for any uniformity that might be exploited.

Complete Solutions

The two best on-the-fly solutions found in my original analysis were a 101 stroke magic formula solution:

print$"x(318%$_/9),(($_-$`)%12?o:x)&($_%12^$'/5?o:'}'),$/x($_/85)for u
+npack<>!~/:/.C12,'XXXXXXXXXXXX'
[download]

and a 102 stroke "baby cart" magic printf string solution:

printf"%@{[.1*vec'XXXXXXXXXXXX',$_,8]}s",($_^$`%12?g:p)&($_^$'/5?g:u)|
+"H

"for map{$_,11-$_}<>!~/:/..5
[download]

Can we improve on these two via a lookup table? Yes!

The first obvious attempt is to combine the vec solutions from sub-problems one, two and three above. When you do that, uniformly encoding 4 bits per value, you get to 100 strokes right away:

sub k{$k=vec'AAAAAAAAAAAAAAAAAA',$i++,4}print$/x k,$"x k,(k^$`%12?o:x)
+&($k^$'/5?o:"}")for<>!~/:/..11
[download]

where AAAAAAAAAAAAAAAAAA is an eighteen character string with ord values 128, 16, 180, 112, 33, 161, 208, 34, 144, 240, 35, 129, 208, 36, 116, 112, 21, 104.

Notice that we switched from trailing newlines to leading newlines to save one stroke, namely a space before the for keyword.

Here's an alternative that's just one stroke longer:

print+($/x($k=vec'AAAAAAAAAAAAAAAAAA',$_,4),$"x$k,($k^$`%12?o:x)&($k^$
+'/5?o:"}"))[$_%3]for<>!~/:/..35
[download]

One more longer still is:

map{$k=vec'BBBBBBBBBBBBBBBBBBB',$_,4;print$_%3?($"^='*')x$k:($k^$`%12?
+o:x)&($k^$'/5?o:"}")}<>=~/:/..36
[download]

where BBBBBBBBBBBBBBBBBBB is a 19 character string with ord values 0, 8, 65, 11, 23, 18, 10, 45, 2, 9, 63, 18, 8, 77, 66, 7, 87, 129, 6.

It's possible I've overlooked a shorter way to avoid multiple calls of vec.

Next, we can try using two separate vec's for the leading spaces and trailing newlines respectively, combined with our winning dreaded ordering formula:

print$"x(vec'CCCCCC',$z,4),($`%12^$z?o:x)&($'/5^$z?o:"}"),$/x(vec'EEE'
+,$z=11-$z+$|--,2)for<>!~/:/..11
[download]

where CCCCCC is a six character string with ord values 120, 253, 125, 72, 1, 65 and EEE is a string with ord values 0, 144, 106. 101 strokes. Using our map generator turns out to be one stroke longer:

print$"x(vec'CCCCCC',$_,4),($`%12^$_?o:x)&($'/5^$_?o:"}"),$/x(vec'FF',
+$_,2)for map{$_,11-$_}<>!~/:/..5
[download]

where FF is a string with ord values 169, 6.

Treating the Clock Face as a Long String

There is yet another promising approach to this game: treat the clock face as a single long string. If you do that, the character positions in the string of each clock face mark are shown below:

        8
   14      22

 26           40

43             59

 63           77

   84      92
       102
[download]

with newlines at character positions: 9, 23, 24, 41, 42, 60, 61, 78, 79, 93.

By ignoring newlines, we can reduce the string length to less than 100, the character positions now being:

        8
   13      21

 23           37

38             54

 56           70

   75      83
       92
[download]

How does that help? Well, if you place the clock face mark character positions in a lookup string in just the right order, you can derive the dreaded ordering from the return value of the Perl index function! And thus avoid having to generate it. Let's see how that might look:

print+($`%12^($x=index'GGGGGGGGGGGGGGGGGGGGGG',chr)?~$x?$x<12?o:$/:$":
+x)&($'/5^$x?o:"}")for<>!~/:/..102
[download]

where GGGGGGGGGGGGGGGGGGGGGG is a 22 character string with ord values 8, 22, 40, 59, 77, 92, 102, 84, 63, 43, 26, 14, 9, 23, 24, 41, 42, 60, 61, 78, 79, 93. Note that the first twelve values in the string are the (ordered) clock face mark positions while the next ten are the position of each newline.

This algorithm simply iterates through the 103 character clock face string, one character at a time, emitting a space, a newline, or a clock face mark (o, m, h, or x) at each character position.

By a fluky coincidence, this program happens to be 103 characters in length, identical in size to the clock face string it draws! :)

The bitwise string operations used in this solution are a bit tricky. Hopefully, the table below will help convince you they are all ok. In particular, note that SPACE (ord 32) has an especially lucky power of two bit pattern; bitwise and'ing any of the letters with it produces a SPACE.

letter	ord
newline	10	0	0	0	0	1	0	1	0
space	32	0	0	1	0	0	0	0	0
h	104	0	1	1	0	1	0	0	0
m	109	0	1	1	0	1	1	0	1
o	111	0	1	1	0	1	1	1	1
x	120	0	1	1	1	1	0	0	0
}	125	0	1	1	1	1	1	0	1

By the way, this character by character approach is especially well-suited to PHP (which does not have a string multiply operator) because it does not require any string multiplication. The idea for this solution was shown to me by leading PHP golfer ToastyX.

Elegant though this solution is, using 22 characters for the lookup string is a bit extravagant. Can we shorten it somehow? We can in Perl simply by dropping the newlines from the lookup string and reverting to generating them via string multiply:

print~($x=index'DDDDDDDDDDDD',chr)?($`%12^$x?g:p)&($'/5^$x?g:u)|H.$/x(
+vec'FF',$x,2):$"for<>!~/:/..92
[download]

where DDDDDDDDDDDD is a twelve character string with ord values 8, 21, 37, 54, 70, 83, 92, 75, 56, 38, 23, 13 and FF is a string with ord values 169, 6. That reduces this approach from 103 down to 100 strokes.

Summary

As discussed above and in my previous analysis, there are at least ten different ways to solve this problem in around 100 strokes. To me, that shows that this was a very well designed golf. Kudos to Arpad Ray for composing it.

Also interesting is that from over 100 entries, only three golfers managed to get below 110 strokes, indicating that this was one of the more difficult golfs.

References

• The golf course looks great, my swing feels good, I like my chances (Part I)
• The golf course looks great, my swing feels good, I like my chances (Part II)
• The golf course looks great, my swing feels good, I like my chances (Part III)
• The golf course looks great, my swing feels good, I like my chances (Part IV)
• The golf course looks great, my swing feels good, I like my chances (Part V)
• The golf course looks great, my swing feels good, I like my chances (Part VI)
• Re: The golf course looks great, my swing feels good, I like my chances (Part VI)
• When One Golfer Speculates On What Another Is Doing...
• Drunk on golf: 99 Bottles of Beer

• jakevoytko Python Saving Time blog
• Abdulla Arif PHP Saving Time blog
• Drew Stephens Perl Saving Time blog
• Tobias Lofgren Perl Saving Time blog
• stackexchange saving time question