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…
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
To achieve it, you can replace the only space with a line break, and since that doesn’t count its one byte off
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. (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
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
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”