python coding contest

[Shane Hathaway]

Szabolcs Nagy wrote:
> my two solutions (well I wasn't so clever to encode everything in
> strings instead of numbers, but at least it won't give warnings about
> non ascii characters):
> 128:
> j,seven_seg=''.join,lambda s:j(j(' |_ |'[i>>3*int(c)&b]for c in s for b
> in(4,2,1))+'\n'for i in(306775170,1060861645,524130191))
> 
> 122:
> seven_seg=lambda s,j=''.join:j(j(' _   _|_| |_
> |'[i>>3*int(c)&14:][:3]for c in s)+'\n'for i
> in(8208,934111592,664455910))

FWIW, here's my 121 character solution that's fully printable.  (Line 
breaks added.)

seven_seg=lambda s,j=''.join:j(j(
'   _ _| |_  |_|'[ord('^-TR5bfmvr'[int(c)])/b%8*2:][:3]for c in s)+'\n'
for b in(64,8,1))

This solution uses the 7 lower bits of every encoded byte, rather than 
the 7 upper bits that the 8 bit solutions use.  8 bits make it possible 
to avoid multiplying by 2, but I wanted this version to use pure ASCII, 
so I had to multiply by 2.  The choice to divide rather than shift is 
important because it allowed me to eliminate parentheses.

It's interesting that there seems to be no room for special cases.  For 
example, the top row has only two states and those states are not used 
by the other rows.  Therefore, the top row could be computed in a much 
simpler way than the other two rows, and the other two rows could be 
simplified by having only 5 possible states rather than 7.  However, all 
my attempts to exploit this property produced larger code.

Shane