TinyCode competition - trial

Second assignment available:
http://213.247.55.3:8484/compileandrun/?assignment=binaryshrink
73 bytes…

Third assignment available:
http://213.247.55.3:8484/compileandrun/?assignment=hex
86 bytes…

I’m adding a database now, to make accounts, and compete against eachother…

72 bytes! muhahaha :slight_smile:

To achieve it, you can replace the only space with a line break, and since that doesn’t count its one byte off :slight_smile:

Hehe… then I get 72 bytes too…

and I got 2 solutions:


for(int
r=0,i=0,b=0;r>-1;b=b<<1|(r=in.read())&1)
if(i++%8==0)out.write(b);


for(int
r,i=0,b=0;(r=in.read())>0;)
{
b=b<<1|r&1;
if(++i%8==0)out.write(b);
}

The first is extremely not-done.

It’s a nice loophole though, and I’ll make sure I’ll ‘fix’ that.

Like… only linebreaks allowed after a ‘{’

Could you show me your solution?

My is a bit different:

for(int
c=0,i=0,x;(x=in.read())>0;c<<=1){
c|=x&1;
if(++i%8<1)out.write(c);
}

And 71 bytes with that:

for(int
r=1,i=0,b=0;r>0;b=b<<1|(r=in.read())&1)
if(i++%8==0)out.write(b);

erm, am I missing something?
2 of the solutions above don’t work?

They output a leading 0 to the output stream.


for(int
r=1,i=0,b=0;r>0;b=b<<1|(r=in.read())&1)
if(i++%8==0)out.write(b);

and


for(int
r=0,i=0,b=0;r>-1;b=b<<1|(r=in.read())&1)
if(i++%8==0)out.write(b);

This doesn’t output a leading zero but all ascii values are 0x100 too high. It looks ok on that web page though. :smiley: (70 bytes)


for(int
r=1,b=1;
r>0;
b=b<<1|(r=in.read())&1)
if(b>255)
{
out.write(b);
b=1;
}

That’s perfectly ok - the contract of OutputStream.write(int) dictates that only the bottom 8 bits are used anyway, so using the upper bits for signalling is pretty damn clever =)

An adaption of the above (66 bytes!) :-

And there is even a redundant ‘;’ in the for, which I’m sure can be optimised away with some restructuring?

Oops - 2 too many parenthesis!
Down still further, to 64bytes!


for(int
b=1;
(b=b<<1|in.read()-48)>0;)
if(b>255){
out.write(b);
b=1;
}

“(b=b<<1|in.read()-48)>0”

shudder

A serious case of ‘know thy operator precedence’ ;D

Damn, this is too much fun.

And we havn’t even moved onto the hex string problem :expressionless:
I fear that is going to be realy horrible!

Tomorrow, I’ll point a few of the guys @ work to this Thread;
it’s a mobile phone games company, so they’re usually up for a ludicrous micro-optimisation challenge! (though normally @ the bytecode, not source-code level :D)

I added a “hex-viewer” at the bottom, so you can check your ‘invisible’ output too.

I honestly didn’t know about the trailing 0-byte in my 72 solution.

I decided to remove all whitespace from the byte-count, even spaces required to compile:
[int a,b,c;] is counted as [inta,b,c;]

I mean… we can all remove new lines and spaces… that’s not where the focus should be.

As an exampe, this is 64 bytes now:


for(int b=1;(b=b<<1|in.read()-48)>0;)
  if(b>255)
  {
     out.write(b);
     b=1;
  }

Fair enough, though it does make declaring types 1 byte cheaper than they should otherwise be.

The spaces could ALL be eliminated by line-breaks…

Otherwise I need to write a pretty darn clever byte-counter, or count linebreaks again, but then i could as well use a textfield instead of a textarea. :-X

A slightly more obfuscated version, unfortunately it’s the same size :frowning:

for(int b=1;(b=b<<1|in.read()-48)>0;)
for(;b>255;b=1)
out.write(b);

it’s dead-easy to remove 1 byte by turning “b<<1” into “b*2” :wink: