This started as a test script while I was learning about bit operations, and it slowly evolved into an obfuscated JAPH. I know it exceeds the traditional "4 line rule", but I thought that it would be fun to limit the digits used to only 0 and 1, given the theme. It was not golfed in any way.

Enjoy!

```
\$_=[[[[{},[]],{0111,'01110111',1000,'11100101'},[[]]],{0001,'01111110'
,0110,'00011010',0100,'011001000011111001111010',0010,'00000100',0011,
'01010101000100000001111110100010101000000000101000110000010001001010'
.'10100',0101,'011100001001010100000001'},[[]]]];%_=%{\${\${\$_}[0]}[1]};
\$s=eval{\$O=0,\$C=0,\$t='This is my 100th PM post';sub{\$O++,\$C=@_?\$C:eval
pack('b*',vec(pack('b*',\$_{1<<(1<<0<<1)*((1<<0+1<<0)+1<<0)}),\$O-1,1<<0
)?\$_{1<<0}:\$_{1<<(1<<1<<1)-1}).\$C.pack('c',vec(pack('b*',\$_{1<<((1<<0)
+(1<<1*1<<1)+1<<0)}),(\$O-1)%((1<<0*1<<1)+1<<0),1<<(1<<0+1<<0)+1)).pack
('b*',vec(pack('b*',\$_{1<<((1<<0+1<<0)+(1<<1<<1))}),\$O-1,1)?\$_{1<<((1+
1<<0)+1)}:\$_{1<<0}).vec(\$t,\$O-1,1<<(1<<1<<1)-(1<<0))};};;\$o=pack('b*',
\$_{((1<<1)**(1<<1)-1)**(1<<1)});for(0..unpack('%b*',\$o)-(1<<1)){\$c=\$_-
((\$_-\$_%(1<<1<<1))/(1<<1<<0*1<<1)+(\$_%(1<<1+1<<0)?1:0));;\$i=(vec(\$o,\$c
,(1<<1<<0+1<<0))+(vec(\$o,\$c+1,(1<<1<<1))<<(1<<1<<0+1))>>((1<<1<<1<<1>>
1)-\$_%(1<<1<<1<<1>>1)-(1<<1<<0+1)*(\$_%(1<<1<<1>>1<<1)?0:1)));\$i+=\$i%(1
<<1)?-1:1 if(((\$_+1)%((1<<1+1<<1)+(1<<1)+(1<<1)))&&!((\$_+1)%((1<<1)**(
1<<1)-1))||\$_+1==(1<<(1<<1+1<<1>>1))+(((1<<1)+1)<<1));\$T=vec(pack('C',
\$i),0,(1<<1<<1>>1<<1))+vec(pack('b*',\$_{(1+((1<<1)**(1<<1))**((1<<1)**
(1<<1)-1))}),\$_,1)*(1<<(1<<(1<<1)))+(1<<((1<<1**1<<1)+1));;print pack(
'c',(\$T+=\$T==(1<<((1<<1+1<<1>>1)+1))?0:(1<<(((1<<1+1<<1)>>1)+(1<<0*1<<
1))))-=\$_%(1+(((1<<1+1<<1)>>1)+(1<<0*1<<1)<<1))==0?(1<<(((1<<1*1<<1<<1
)+(1<<1<<1>>1))>>1)):0);&\$s}print pack('c',\$s->(1<<0)^unpack('c',(pack
('b*',\$_{(1<<1*1<<1*1<<1)*((1<<1)**(1<<0<<1)-1)**(1<<1<<1>>1<<0)}))));

Hint: the bit shifts are fun, but they aren't the main point of the obfuscation.

Tested on

• perl 5.005_03 built for i386-linux (little endian)
• perl 5.6.0 built for sun4-solaris (big endian)
• perl 5.6.1 built for MSWin32-x86-multi-thread (little endian)
• perl 5.8.0 built for i386-linux-thread-multi (little endian)
• perl 5.8.3 built for i686-linux (little endian)
• perl 5.8.4 built for i386-linux-thread-multi (little endian)

Replies are listed 'Best First'.
Re: Bits & pieces
by jdalbec (Deacon) on Jul 16, 2005 at 03:18 UTC

Good job! Included below is an explanation of this JAPH which is a bit (ba-dum-bum) more verbose. Your analysis hit on the big points, but I wanted to fill in some of the more subtle reasoning.

the two characters are negated in alternate calls to the closure.
For that to be true, \$_{64} would have to be '010101010101010101010101'. But I see that the output of the closure is more predictable than I had thought at first. The final result depends only on the last three (to some extent, six) characters of the string (in fact it's the same as the last character of the string).
```\$O = 19, \$C = ~\$C& 0x4D; # bits 7+ all 0
\$O = 20, \$C = ~\$C| 0x20; # bits 7+ all 1
\$O = 21, \$C = ~\$C^ 0x70; # bits 7+ all 0 bits 6543210
\$O = 22, \$C =  \$C&~0x6F; # bits 7+ all 0      00?0000
\$O = 23, \$C = ~\$C| 0x73; # bits 7+ all 1      1111111
\$O = 24, \$C =  \$C^~0x74; # bits 7+ all 0      1110100
```# 0 4294967295 105  8 4294967263  73  8 4294967263  77  4 4294967291