• (cs)

    WOW. That's not "reinventing the wheel". That is Reinventing Fire!!!

  • daef (unregistered)

    TRWTF is the endianess... LSB should be on [0] in my opinion...

  • daef (unregistered)

    yeah - every coder should know that there is an OR statement for things like this...:

    var rules = [];

if ( inputInt == 1
  || inputInt == 3
  || inputInt == 5
  || inputInt == 7
  || /* snip */ )
   rules[0] = 1;
else
   rules[0] = 0;

if ( inputInt == 2
  || inputInt == 3
  || inputInt == 6
  || inputInt == 7
  || /* snip */ )
   rules[1] = 1;
else
   rules[1] = 0;

if ( inputInt == 4
  || inputInt == 5
  || inputInt == 6
  || inputInt == 7
  || /* snip */ )
   rules[2] = 1;
else
   rules[2] = 0;
    </sarcasm>
  • ColdHeart (unregistered)

    really people... make it a function and stop copying code everywhere!

  • (cs)

    Cue large number of horrendously bad attempts at writing this in [one line/a language of choice/a highly obfuscated manner] that should make any competent programmer weep for the future of humanity...

  • TheSHEEEP (unregistered)

    What... uh... oh god... strange noise

    I don't see the WTF here.

    I only see a vast green pasture with some happy animals on it. It seems very peaceful and looking at it comforts me and restores my inner balance.

  • (cs) in reply to ParkinT

    He used integers. I suppose it could be worse; he might have used booleans, and we all know how much trouble people like this have with the complexity of booleans!

  • Ron (unregistered)

    Paid (or otherwise incentivized) by lines of code, I'll bet. This is why you have to reward what you want, not unrelated measures you think might get you closer to what you want.

  • Smug Unix User (unregistered)

    Make sure to subtly change the function in places and have code dependencies on it working slightly differently.

  • Larry (unregistered)

    for $R (0 .. 7) { $Rules[$R] = ( inputInt == int(inputInt/2)*2 ? 0 : ( inputInt == int(inputInt/4)*4 ? 0 : (

    Oh, hell. I give up. If it works, don't fix it.

  • Reggie (unregistered)

    You have a problem. You think "I know, I'll use bits." Now you have 10 problems.

  • Jaloopa (unregistered) in reply to Ron
    Ron:
    Paid (or otherwise incentivized) by lines of code, I'll bet. This is why you have to reward what you want, not unrelated measures you think might get you closer to what you want.

    Ok, seriously - has anybody ever actually known a job where people are paid by the line? It comes up every time a verbose piece of code is featured but I find it hard to believe that even the pointiest haired of bosses would think it's a good idea

  • Honnza (unregistered)

    Here's an implementation in Javascript:

    Number.prototype.to8bitLEArray = function(){
  return ("00000000"+(this|0).toString(2)).split("").slice(-8);
}
  • Andrew (unregistered)

    I would have said ArrayIndexOutOfBoundsException, but the "var rules = [];" suggests that this is Javascript.

  • Uh... (unregistered) in reply to Hmmmm

    Like this?

    rules = [int(x) for x in "{:08b}".format(inputInt)]

  • Frz (unregistered) in reply to Honnza
    Honnza:
    Here's an implementation in Javascript: 
    Number.prototype.to8bitLEArray = function(){
  return ("00000000"+(this|0).toString(2)).split("").slice(-8);
}

    Nice.. but extending builtin "Types" brings more problems than it solves.

  • (cs) in reply to Reggie
    Reggie:
    You have a problem. You think "I know, I'll use bits." Now you have 10 problems.

    Don't mind if I use this extensively with other quotes.

  • (cs) in reply to Jaloopa
    Jaloopa:
    Ron:
    Paid (or otherwise incentivized) by lines of code, I'll bet. This is why you have to reward what you want, not unrelated measures you think might get you closer to what you want.

    Ok, seriously - has anybody ever actually known a job where people are paid by the line? It comes up every time a verbose piece of code is featured but I find it hard to believe that even the pointiest haired of bosses would think it's a good idea

    Not by the line, but I have worked at a place where they tried paying incentives ($25) per bug fix - the idea being that folks would rip through the bug list and make the app perfect.

    What they forgot to do was put in a charge of $50 for every new bug introduced!

  • John (unregistered)

    So how did they deal with porting this code to a 16-bit machine?

    The pending 64-bit upgrade must be truly impressive ...

  • (cs) 
    template<class CharT>
bool boolify(CharT c) {
    return c == '1';
}

template<class OutputIterator, std::size_t N>
void to_bit_sequence(std::bitset<N> bits, OutputIterator out) {
    std::string str = bits.to_string();

    std::transform(str.begin(), str.end(), out, boolify<char>);
}

int main(int argc, char** argv) {
    if(argc != 2) return 1;
    
    std::vector<bool> out;

    to_bit_sequence(std::bitset<8>(argv[1]), out.begin());
    std::transform(out.begin(), out.end(), 
            std::ostream_iterator(std::cout, ", "));
}
  • Nonody (unregistered) in reply to Reggie

    In fact you'll have 99 problems, but the bits aint one

  • History Teacher (unregistered)

    Ouch. Why does this suddenly give me a headache? I mean, it's just regular WTF quality code, nothing to see here really... Strange.

    As a mental exercise, think, when did things go wrong in the creation of this code? What was the exact event, where reality and sanity parted ways in this case?

  • urza9814 (unregistered) in reply to History Teacher
    History Teacher:
    As a mental exercise, think, when did things go wrong in the creation of this code? What was the exact event, where reality and sanity parted ways in this case?

    ...when the author of this WTF was hired?

  • (cs)

    This is crying out for an enterprise-y database solution. That way it can be easily extended to 64 bits!

  • (cs)

    Now back that function up with 256 individual JSunit test cases and you're golden. Oh, but wait, it isn't a function. Guess you'll have copy-paste the tests too for each place in which this code is used. On the plus side, your code coverage will look amazing.

    Each if-block is about 294 bytes. 256 blocks makes 75KB uncompressed. I'm sure the users of that website will appreciate how fast it loads!

  • AGray (unregistered)

    I'm a C# guy...why couldn't they do something along the lines of...

    [Flags]
public enum FlagSystem
{
  A = 0,
  B = 1,
  C = 2,
  // ...
  N = N ^ 2
}

short mask = FlagSystem.A | FlagSystem.B | FlagSystem.N;

    It's not that tough of a concept, though I haven't used flags in months and have probably botched the above code big time. :(

  • flyboyfred (unregistered)

    What's beautiful about this code is how well it scales. Imagine how easy it would be to extend it to 16 or 32 bits!

  • Sweet Brown (unregistered)

    Ain't nobody got time for that.

    Where's the easy reader version? :P

  • Peter (unregistered) in reply to Jaloopa
    Ok, seriously - has anybody ever actually known a job where people are paid by the line?

    Those jobs are hard to come by and their availability is a closely guarded secret by those who are making a fortune from them

  • (cs) in reply to Jaloopa
    Jaloopa:
    Ron:
    Paid (or otherwise incentivized) by lines of code, I'll bet. This is why you have to reward what you want, not unrelated measures you think might get you closer to what you want.
    Ok, seriously - has anybody ever actually known a job where people are paid by the line? It comes up every time a verbose piece of code is featured but I find it hard to believe that even the pointiest haired of bosses would think it's a good idea

    A major factor in the rift between IBM and Microsoft over OS/2 was that IBM was pressuring Microsoft to write more lines of code. Bill Gates likened it to paying for a new aircraft design by the pound. Of course, that's still not any individual being paid by the line, but I assume that IBM's coders on OS/2 were being incentivized in some way to write more lines.

  • Antti Nagesh (unregistered) in reply to Reggie
    Reggie:
    You have a problem. You think "I know, I'll use bits." Now you have 10 problems.

    This should be a featured comment!

  • Tronic (unregistered)

    as far as code goes, I like the simple but readable version. var rules[]; for( int i = 0; i<8; i++){ rules[i]=inputInt%(2^i); }

  • 3rd Ferguson (unregistered) in reply to flyboyfred
    flyboyfred:
    What's beautiful about this code is how well it scales. Imagine how easy it would be to extend it to 16 or 32 bits!

    Actually...

    You could extend to 64 bits by pushing 8 rules[] into a rulesSixtyFour[]. Not sure how to populate it, though. Maybe do modulo 2^32, 2^31, 2^30, ..., 2^25 on the input to figure which of the eight rules[] arrays to operate on. Within each array you might do modulo eight more times to figure which bit to set.

    It's still horrible but at least it's actually fewer operations than the original code. For nostalgia and backwards compatibility I guess you could leave the original for setting the last 8 bits.

    Don't get uppity if I'm totally wrong, this morning's cappuccino is only half gone...

  • Rodnas (unregistered)

    And now our faculty rules:

    ---snip--- Rule six: There is NO rule six. rule seven: No Poeftas

  • pencilcase (unregistered) in reply to snoofle
    snoofle:
    Jaloopa:
    Ron:
    Paid (or otherwise incentivized) by lines of code, I'll bet. This is why you have to reward what you want, not unrelated measures you think might get you closer to what you want.

    Ok, seriously - has anybody ever actually known a job where people are paid by the line? It comes up every time a verbose piece of code is featured but I find it hard to believe that even the pointiest haired of bosses would think it's a good idea

    Not by the line, but I have worked at a place where they tried paying incentives ($25) per bug fix - the idea being that folks would rip through the bug list and make the app perfect.

    What they forgot to do was put in a charge of $50 for every new bug introduced!

    I worked at a place (long ago) where they had previously paid guys by the number of COBOL modules they wrote. This obviously led to an outpouring of modules performing e.g. "Return 1" equivalent. Fortunately, it was fairly easy to mop them up and laugh a bit.

  • goom (unregistered) in reply to Tronic
    Tronic:
    as far as code goes, I like the simple but readable version. var rules[]; for( int i = 0; i<8; i++){ rules=inputInt%(2^i); }
    That certainly works but as [i]daef pointed out the rules are big-endian while your loop puts them in little-endian order (or do I have it backwards?).

    Assuming that the endianess is required, I would do something like this:

    rules[0] = inputInt & 128;
rules[1] = inputInt & 64;
rules[2] = inputInt & 32;
rules[3] = inputInt & 16;
rules[4] = inputInt & 8;
rules[5] = inputInt & 4;
rules[6] = inputInt & 2;
rules[7] = inputInt & 1;
  • (cs) in reply to Jaloopa
    Jaloopa:
    Ok, seriously - has anybody ever actually known a job where people are paid by the line? It comes up every time a verbose piece of code is featured but I find it hard to believe that even the pointiest haired of bosses would think it's a good idea

    In a recent project I worked on, we weren't being paid for lines of code but management was very, very interested in keeping metrics on them. We would frequently have to submit statistics (or they would be calculated from tools we used). How many lines of code did you produce this week? How long did it take your peers to code review? Therefore, how many LOC/minute do they review? How many bugs came out of this section of code? How many LOC/bug? How many LOC in your module? Compared to every other module? etc, etc, etc. It was kind of nuts, but at least it didn't really get in the way of the job itself.

    They were trying to quantify things like, given an average of X lines impacted per bug, and it takes Y hours to fix, therefore how many bugs can a developer fix per day, therefore we can schedule in Z bug fixes per week...

  • noname (unregistered)

    Well, that's impressive 2304 lines of code. One cent per line makes it $23.04. If he takes longer than half an hour he wasted his and his employers money.

  • (cs) in reply to Antti Nagesh
    Antti Nagesh:
    Reggie:
    You have a problem. You think "I know, I'll use bits." Now you have 10 problems.
    This should be a featured comment!
    And now it won't be, you insensitive clod.
  • Techpaul (unregistered) in reply to snoofle
    snoofle:
    He used integers. I suppose it could be worse; he might have used booleans, and we all know how much trouble people like this have with the complexity of booleans!

    Hmm

    Nah it should XML encoded strings of floats to be really sure he captured EVERY possibility including sign, infinity and of course NaN

  • Kanitatlan (unregistered)

    But just wait until you see the code to translate the rules back into a value, I have. Its munitions grade bad code and hence health & safety forbids posting it.

  • (cs) in reply to urza9814
    urza9814:
    History Teacher:
    As a mental exercise, think, when did things go wrong in the creation of this code? What was the exact event, where reality and sanity parted ways in this case?

    ...when the author of this WTF was hired?

    ...straight out of school.

    Perhaps next time they should wait until after graduation.

  • Foo Bar (unregistered) in reply to Techpaul
    EVERY possibility including sign, infinity and of course NaN
    You forgot File Not Found. Also, Poland.
  • JR (unregistered)

    hum higher order bit is with index 7! Wait other way! it's zero.

  • gpsguru (unregistered) in reply to ParkinT

    Duh, he should have used a switch statement.

  • Snowrat (unregistered)

    rules←inputInt⊤⍨8/2 rules←2|⌽⌊{⍵÷2}\8/inputInt

    The later one is my favourite so far.

  • David Emery (unregistered)

    The interesting thing about the code sample is that any reasonably competent compiler will take at least the assignment code and optimize it. An even better compiler will recognize the whole thing is -static code- and produce a very tight representation.

    Those of you who propose generating this with some functions should recognize that, depending on the expression, the programming language and the quality of the compiler, you'll end up running that code when you didn't have to.

  • d (unregistered) in reply to ParkinT
    ParkinT:
    WOW. That's not "reinventing the wheel". That is Reinventing Fire!!!
    Using kerosene.
  • Nico (unregistered) in reply to Reggie

    I don't get that... Shouldn't it be

    "You have two problems. You think "I know, I'll use bits." Now you have 10 problems."

  • (cs) in reply to goom
    goom:
    Tronic:
    as far as code goes, I like the simple but readable version. var rules[]; for( int i = 0; i<8; i++){ rules=inputInt%(2^i); }
    That certainly works but as [i]daef pointed out the rules are big-endian while your loop puts them in little-endian order (or do I have it backwards?).

    Assuming that the endianess is required, I would do something like this:

    rules[0] = inputInt & 128;
rules[1] = inputInt & 64;
...
rules[7] = inputInt & 1;

    That... or just:

    int size; // E.g. rules.size() or something
for(int i=0;i<size;i++) {
    rules[i] = inputInt & (1 << (size-i));
}
</pre>

    (Parentheses added for clarity, not actually necessary)

Leave a comment on “A Bit Misguided”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article