• (cs) in reply to Grammar Nazi Prick
    Grammar Nazi Prick:
    C-Octothorpe:
    boog:
    ted:
    So, about 500 more posers are going to show us how smart they are that they've heard of Gray codes.
    Bullshit. None of the articles on this site get that many comments.

    Your estimate is way off.

    You're wrong. There are that many posts, but we're silenced by the forum admins who keep deleting gems like "No, YOUR a racist loser!"

    FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU! FUCK YOU!

    I think I have an admirer...

  • Paul (unregistered)

    TRWTF is "impromptu."

  • Anon (unregistered) in reply to Kuba

    Please explain to me how you expect this to work? I'm not C++0x coder, but I can't see how that operator could ever return an un-even value, since the last statement in the loop is effectively a multiply by 2.

  • Anon (unregistered) in reply to Kuba
    Kuba:
    Doug:
    Here's the interesting part that blows your comment away: it's really, really hard to put that prefix on accidentally: "0x POS_9" and "0xPOS_9" won't compile. However, you can do:

    #define PREFIX_X(x,y) x##y #define PREFIX(x,y) PREFIX_X(x,y) int x = PREFIX(0x,POS_9); /* x=0x1001 by preprocessor magic */

    I would say that's pretty obvious that you're making it hex, though, even if the preprocessor magic is counter intuitive.

    So, no -- POS_9 is always "one thousand and one" even though it's a define.

    That's where user defined literals in C++ 11 (née 0x) come handy.
    #include <iostream>
    constexpr int operator ""b (const char *s, size_t n) {
    int r = 0;
    while (n--) {
    static_assert(s[n] == '1' || s[n] == '0');
    if (s[n] == '1') r |= 1;
    r = r << 1;
    }
    return r;
    }
    int main()
    {
    cout << 1001b << endl; // outputs 9
    }
    Unfortunately, no shipping version of gcc can compile this AFAIK

    Above should have quoted this.

  • Childish (unregistered) in reply to Doug
    Doug:
    NoAstronomer:
    Ahem:
    To everyone who doesn't get it:

    The numbers in the defines aren't in binary.

    1001 is one thousand and one, not nine.

    Not even that. It's a #define. So in some places itmay be one thousand and one. In other places it could be nine. Or not.

    Uh, no.

    The only way you can get POS_9 to act like anything but "one thousand and one" is to prefix it to change the base:

    0x1001 (four thousand and ninety-seven) 01001 (five hundred and thirteen)

    Some compilers support 0b as a prefix for binary literals, but that's not standard.

    Here's the interesting part that blows your comment away: it's really, really hard to put that prefix on accidentally: "0x POS_9" and "0xPOS_9" won't compile. However, you can do:

    #define PREFIX_X(x,y) x##y #define PREFIX(x,y) PREFIX_X(x,y) int x = PREFIX(0x,POS_9); /* x=0x1001 by preprocessor magic */

    I would say that's pretty obvious that you're making it hex, though, even if the preprocessor magic is counter intuitive.

    So, no -- POS_9 is always "one thousand and one" even though it's a define.

    That is how you exp(WTF). The original C radix WTF was much simpler than the CPP crap here.

    base2(1001) is just 9 in either Hex or Decimal. The WTF code doesn't even clear decimal(10).

  • (cs) in reply to Doug
    Doug:
    ParkinT:
    There are 10 types of people: - Those who understand binary - Those who don't
    - And those who mistake it for ternary

    There are three sorts of people in the world: those who can count and those who can't.

  • (cs) in reply to Jaime
    Jaime:
    boog:
    pWidget->nCurrentPosition = DIO_Input & 15; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Better?

    No.
    Really? It sure seems to resolve the issue you pointed out. Oh well, I guess some people are never happy.

    Jaime:
    That comment wasn't about the code being wrong, it was about Bernhardus providing a fix but putting as little thought into it as the original developer did and making a classic re-write mistake.
    For you, perhaps the motivations for writing accurate code for a production environment almost exactly reflect the motivations for writing accurate code in an internet post. I, on the other hand, will gladly assume that had this been the real world, Bernhardus would have put more thought into it and would have tested his code to identify the mistake you pointed out.

    I do recognize that, as a pessimist, such an assumption is a bit out of character for me. But I admit that Bernhardus' mistake is the type I might make, which is why I advocate peer reviews and thorough testing.

    Jaime:
    It's a good idea to not re-write WTFy but functional code without giving it a good deal of thought because new bugs are often introduced.
    I'm with you on this; I've said for years that functioning code shouldn't be modified without any functional benefit. Not a fan of the "R" word, I'm not.
  • (cs)

    If you remember what grade you were taught some specific skill, chances are you're not that experienced.

  • (cs) in reply to frits
    frits:
    If you remember what grade you were taught some specific skill, chances are you're not that experienced.

    Fair comment, but in this case I specifically remember the teacher. She was memorable, even at the tender pre-pubescent age that I was. A dead ringer for Chrissie Hynde, and with an even more sultry voice. Some experiences stay with you for life.

  • Cyt (unregistered) in reply to Silfax
    Silfax:
    verisimilidude:
    I am reminded of: There are 10 kinds of people in the world: those that understand binary and those that don't

    According to the code that was posted there should be 11 kinds of people that understand binary, those that do, those that don't and those that think they do.

    But... that's only three?

  • Cyt (unregistered)
    #define POS_0 Doublerize("0000")
    #define POS_1 Doublerize("0001")
    #define POS_2 Doublerize("0010")
    #define POS_3 Doublerize("0011")
    #define POS_4 Doublerize("0100")
    #define POS_5 Doublerize("0101")
    #define POS_6 Doublerize("0110")
    #define POS_7 Doublerize("0111")
    #define POS_8 Doublerize("1000")
    #define POS_9 Doublerize("1001")
    
    ...snip...
    
    char Clever[16];
    sprintf(Clever, "%d", DIO_Input);
    int bit0 = (fmod(Doublerize(DIO_Input),2)< 0.00001) ? 0 : 1;
    int bit1 = (fmod(Doublerize(DIO_Input),4) < 0.00001) ? 0 : 1;
    int bit2 = (fmod(Doublerize(DIO_Input),8) < 0.00001) ? 0 : 1;
    int bit3 = (fmod(Doublerize(DIO_Input),16) < 0.00001) ? 0 : 1;
    
    // no need normalize (speed-optimisation)
    
    
    // Memory optimise, reuse the clever string
    sprintf(Clever, "%d%d%d%d", bit3, bit2, bit1, bit0);
    double Position = Doublerize(Clever);
    ...snip...
    
    // Which position is engaged?
    switch ((int)Position)
    {
       case POS_0: {
           pWidget->nCurrentPosition = 0;
           pWidget->sCurrentPosition = pWidget->m_sPositionName_0;
           break;
           }
       case POS_1: {
           pWidget->nCurrentPosition = 1;
           pWidget->sCurrentPosition = pWidget->m_sPositionName_1;
           break;
           }
      ...snip...
       case POS_9: {
           pWidget->nCurrentPosition = 9;
           pWidget->sCurrentPosition = pWidget->m_sPositionName_9;
           break;
           }
       }
    
    

    FTFY

  • (cs) in reply to Kuba
    Kuba:
    That's where user defined literals in C++ 11 (née 0x) come handy... constexpr int operator ""b (const char *s, size_t n) {
    ARE YOU KIDDING ME? Operator overloading isn't enough, now we need literal overloading? I mean, if you need that to write a WTF in C++, you're sorely lacking imagination.
  • drgreenthumb (unregistered)

    TRWTF is that the entire project could be replaced by a simple photo interrupter and some small counting code on interrupt on a microcontroller.

    I could build this for $5 and in about 10 minutes on a solderless prototype board.

  • Potato (unregistered)

    At first I couldn't see the problem, probably because some primal part of my brain was blocking it out. As I stared for a minute longer however, the only words were "Oh god... Oh my god... OH GOD!" Except in shock, not orgasm.

  • jb (unregistered) in reply to Paul
    Paul:
    TRWTF is "impromptu."

    no, impromputU!

  • (cs) in reply to Kuba
    Kuba:
    That's where user defined literals in C++ 11 (née 0x) come handy.
    #include <iostream>
    constexpr int operator ""b (const char *s, size_t n) {
      int r = 0;
      while (n--) {
        static_assert(s[n] == '1' || s[n] == '0');
        if (s[n] == '1') r |= 1;
        r = r << 1;
      }
      return r;
    }
    int main()
    {
      cout << 1001b << endl; // outputs 9
    }
    Unfortunately, no shipping version of gcc can compile this AFAIK
    So TRWTF is you expecting that compilers released before the standard was finalised would somehow travel forward in time, learn what the standard was going to say, implement it all by themselves using artificial intelligence, then travel backwards in time to before the spec was released so that you could use the new functionality that only came out after the compiler was released before it was released?

    OK, that makes sense. backs slowly away

  • 32gen (unregistered) in reply to ParkinT
    ParkinT:
    There are 10 types of people: - Those who understand binary - Those who don't
    Wait, what happened to the other 0xE types?
  • Shinobu (unregistered)

    Actually, from looking at this code I have to disagree with the cleverness of the hardware. Depending on the exact nature of the ‘notches’ this may be big or a small problem, but encoding your positions like this potentially opens you up to a race condition. Consider using a Gray code instead.

  • Anon (unregistered) in reply to Kuba
    Kuba:
    Doug:
    Here's the interesting part that blows your comment away: it's really, really hard to put that prefix on accidentally: "0x POS_9" and "0xPOS_9" won't compile. However, you can do:

    #define PREFIX_X(x,y) x##y #define PREFIX(x,y) PREFIX_X(x,y) int x = PREFIX(0x,POS_9); /* x=0x1001 by preprocessor magic */

    I would say that's pretty obvious that you're making it hex, though, even if the preprocessor magic is counter intuitive.

    So, no -- POS_9 is always "one thousand and one" even though it's a define.

    That's where user defined literals in C++ 11 (née 0x) come handy.
    #include <iostream>
    constexpr int operator ""b (const char *s, size_t n) {
    int r = 0;
    while (n--) {
    static_assert(s[n] == '1' || s[n] == '0');
    if (s[n] == '1') r |= 1;
    r = r << 1;
    }
    return r;
    }
    int main()
    {
    cout << 1001b << endl; // outputs 9
    }
    Unfortunately, no shipping version of gcc can compile this AFAIK

    Please, do explain, how this code ever can return an uneven number?

  • (cs)

    A vendor was trying to explain to me how their storage tank level monitoring system worked, with a float on a cable that spooled up and down and black and white marks on the spool and an optical device that noticed when black changed to white, etc. I was thinking at the time "how quaint." Now thanks to this thread about Gray Code I understand it was actually sort of The Right Thing.

  • (cs) in reply to Anon
    Anon:
    Kuba:
    Doug:
    Here's the interesting part that blows your comment away: it's really, really hard to put that prefix on accidentally: "0x POS_9" and "0xPOS_9" won't compile. However, you can do:

    #define PREFIX_X(x,y) x##y #define PREFIX(x,y) PREFIX_X(x,y) int x = PREFIX(0x,POS_9); /* x=0x1001 by preprocessor magic */

    I would say that's pretty obvious that you're making it hex, though, even if the preprocessor magic is counter intuitive.

    So, no -- POS_9 is always "one thousand and one" even though it's a define.

    That's where user defined literals in C++ 11 (née 0x) come handy.
    #include <iostream>
    constexpr int operator ""b (const char *s, size_t n) {
    int r = 0;
    while (n--) {
    static_assert(s[n] == '1' || s[n] == '0');
    if (s[n] == '1') r |= 1;
    r = r << 1;
    }
    return r;
    }
    int main()
    {
    cout << 1001b << endl; // outputs 9
    }
    Unfortunately, no shipping version of gcc can compile this AFAIK

    Please, do explain, how this code ever can return an uneven number?

    That's the good part of this feature of C++0x 11 née whatever: you can make ...b make to mean: the number in binary times two. Extremely useful.

    BTW, née is French for born, and carries the feminine suffix. So... C++0x is female. WTF?

  • iToad (unregistered) in reply to Bob
    Bob:
    For a moment I thought maybe they somehow made the compiler treat integer literals as binary, but then there's this:
    int bit0 = DIO_Input & 1;
    int bit1 = DIO_Input & 2;
    int bit2 = DIO_Input & 4;
    int bit3 = DIO_Input & 8;

    Yep, use of the magic numbers 1, 2, 4, 8 ... for bit fields. I use:

    int bit0 = DIO_Input & (1<<0);
    int bit1 = DIO_Input & (1<<1);
    int bit2 = DIO_Input & (1<<2);
    int bit3 = DIO_Input & (1<<3);
    ...
    int bit9 = DIO_Input & (1<<9);
    ...
    int bit15 = DIO_Input & (1<<15);
    

    Any halfway-decent optimizing compiler turns the constant shift expressions into constants. I know that gcc does it, because I checked.

  • a noid (unregistered) in reply to TGV
    TGV:
    Anon:
    Kuba:
    Doug:
    Here's the interesting part that blows your comment away: it's really, really hard to put that prefix on accidentally: "0x POS_9" and "0xPOS_9" won't compile. However, you can do:

    #define PREFIX_X(x,y) x##y #define PREFIX(x,y) PREFIX_X(x,y) int x = PREFIX(0x,POS_9); /* x=0x1001 by preprocessor magic */

    I would say that's pretty obvious that you're making it hex, though, even if the preprocessor magic is counter intuitive.

    So, no -- POS_9 is always "one thousand and one" even though it's a define.

    That's where user defined literals in C++ 11 (née 0x) come handy.
    #include <iostream>
    constexpr int operator ""b (const char *s, size_t n) {
    int r = 0;
    while (n--) {
    static_assert(s[n] == '1' || s[n] == '0');
    if (s[n] == '1') r |= 1;
    r = r << 1;
    }
    return r;
    }
    int main()
    {
    cout << 1001b << endl; // outputs 9
    }
    Unfortunately, no shipping version of gcc can compile this AFAIK

    Please, do explain, how this code ever can return an uneven number?

    That's the good part of this feature of C++0x 11 née whatever: you can make ...b make to mean: the number in binary times two. Extremely useful.

    BTW, née is French for born, and carries the feminine suffix. So... C++0x is female. WTF?

    What's wrong with playing with females for productive purposes?

  • Flogged2Death (unregistered) in reply to Silfax
    Silfax:
    verisimilidude:
    I am reminded of: There are 10 kinds of people in the world: those that understand binary and those that don't

    According to the code that was posted there should be 11 kinds of people that understand binary, those that do, those that don't and those that think they do.

    You mean those that do, those that don't and those that FILE_NOT_FOUND?

  • Herby (unregistered) in reply to Silfax
    Silfax:
    verisimilidude:
    I am reminded of: There are 10 kinds of people in the world: those that understand binary and those that don't

    According to the code that was posted there should be 11 kinds of people that understand binary, those that do, those that don't and File not found.

    FTFY! (I couldn't resist)

  • Herby (unregistered) in reply to Herby
    Herby:
    Silfax:
    verisimilidude:
    I am reminded of: There are 10 kinds of people in the world: those that understand binary and those that don't

    According to the code that was posted there should be 11 kinds of people that understand binary, those that do, those that don't and File not found.

    FTFY! (I couldn't resist)

    A little late, but the thought is there!

  • Sean Ellis (unregistered)

    There are 10 kinds of people in the world:

    • Those that know binary
    • Those that don't
    • Those that mistake it for ternary
    • Those that say "What's io?"
    • Annoying pedants who passive-aggressively point out the arbitrary base by making a list of alternatives with N entries. (N=5)

    Oh bother.

  • (cs) in reply to TGV
    TGV:
    Anon:
    Kuba:
    That's where user defined literals in C++ 11 (née 0x) come handy.

    Please, do explain, how this code ever can return an uneven number?

    That's the good part of this feature of C++0x 11 née whatever: you can make ...b make to mean: the number in binary times two. Extremely useful.

    BTW, née is French for born, and carries the feminine suffix. So... C++0x is female. WTF?

    Without getting into a long discussion about gender roles in society, it's currently pretty much necessary to be female in order to have a maiden name.

    I am, however, slightly surprised by the implication that Miss C++ 0x got married to a Mr. 11.

  • (cs) in reply to Bernhardus

    Actually, you may still need to filter the high bits of DIO_Input, which may indicate other information, like if a button is being pushed as well.

    Why make an array of strings part of the object? Notice that sCurrentPosition is dependant on nCurrentPosition, therefore make sCurrentPosition a function that returns a string from an array of constants defined inside function. No need to store the string in each instance of the class.

    pWidget->nCurrentPosition = DIO_Input & 15;
    sName = pWidget->sCurrentPosition();
    
  • Jeff Grigg (unregistered)

    Arghhh! Eyes bleed!

  • js (unregistered)

    The only thing the code author gets even a 'B' grade on is... mmm .... mmmmmmmmm ... indentation - maybe.

  • C (unregistered) in reply to Doug
    Doug:
    Uh, no.

    The only way you can get POS_9 to act like anything but "one thousand and one" is to prefix it to change the base:

    0x1001 (four thousand and ninety-seven) 01001 (five hundred and thirteen)

    Some compilers support 0b as a prefix for binary literals, but that's not standard.

    Here's the interesting part that blows your comment away: it's really, really hard to put that prefix on accidentally: "0x POS_9" and "0xPOS_9" won't compile. However, you can do:

    #define PREFIX_X(x,y) x##y #define PREFIX(x,y) PREFIX_X(x,y) int x = PREFIX(0x,POS_9); /* x=0x1001 by preprocessor magic */

    I would say that's pretty obvious that you're making it hex, though, even if the preprocessor magic is counter intuitive.

    So, no -- POS_9 is always "one thousand and one" even though it's a define.

    What's wrong with:

    ... in an obscure include[d] file ... #define Normalize(y) 0x##y

    ... snip ...

    int x = Normalize(POS_9); /* x=0x1001 by preprocessor magic */

  • The DCB Harbinger (unregistered)

    I, for one, can only welcome this development!

    For decades in the past, BCD (or Binary-Coded Decimal) representations ruled the world of small computing devices.

    But now, finally, we see a turnabout! DCB, the magnificent Decimal-Coded Binary, finally begins to assert its presence!

  • The Poop... of DOOM (unregistered)

    This reminds me of when I was 8 and was trying to make games in QBasic, all graphics being straight outputs in ASCII, and one huge pile of gotos for each possible chain of keypresses made (didn't know the concept of variables when I was 8). Got me puzzled why the hell it didn't work :P That "code" was at about the same level as this, with the same amount and level of awkwardness.

    Oh, and I don't know that Gray's Anatomy thingy, but as plenty of folks have pointed it out, I shall be clever and show my knowledgability.

    Why didn't the guy use this Gray's Anatomy thingy?

  • (cs) in reply to Anon
    Anon:
    Please explain to me how you expect this to work? I'm not C++0x coder, but I can't see how that operator could ever return an un-even value, since the last statement in the loop is effectively a multiply by 2.
    Yeah, a standard mistake of yours truly. Easy to fix ;)
  • (cs) in reply to DaveK
    DaveK:
    TGV:
    Anon:
    Kuba:
    That's where user defined literals in C++ 11 (née 0x) come handy.

    Please, do explain, how this code ever can return an uneven number?

    That's the good part of this feature of C++0x 11 née whatever: you can make ...b make to mean: the number in binary times two. Extremely useful.

    BTW, née is French for born, and carries the feminine suffix. So... C++0x is female. WTF?

    Without getting into a long discussion about gender roles in society, it's currently pretty much necessary to be female in order to have a maiden name.

    I am, however, slightly surprised by the implication that Miss C++ 0x got married to a Mr. 11.

    Nope. She was born 0x and now, after a name change, is called 11. I don't know why I always thought of C++ in feminine, but there you go. Pascal was always a bearded guy, though ;)

  • (cs) in reply to DaveK
    TGV:
    That's the good part of this feature of C++0x 11 née whatever: you can make ...b make to mean: the number in binary times two. Extremely useful.
    ;)
    DaveK:
    TGV:
    BTW, née is French for born, and carries the feminine suffix. So... C++0x is female. WTF?
    Without getting into a long discussion about gender roles in society, it's currently pretty much necessary to be female in order to have a maiden name.

    I am, however, slightly surprised by the implication that Miss C++ 0x got married to a Mr. 11.

    Nope. She was born 0x and now, after a name change, is called 11. I don't know why I always thought of C++ in feminine, but there you go. Pascal was always a bearded guy, though ;)

  • Anonymous Cow-Herd (unregistered) in reply to Kuba
    Kuba:
    I don't know why I always thought of C++ in feminine, but there you go.
    I'm sure someone less enlightened would make some joke about it being a complete bitch at times, but not me. Oh no, sir.
  • Adam (unregistered) in reply to boog
    boog:
    Jaime:
    RogerC:
    Bernhardus:
    So the code extracts the four bits from the input number DIO_Input, then converts it to the binary representation in decimal. Finally the data member nCurrentPosition is assigned the actual value.

    What is interesting is that DIO_Input already contains the actual value; there isn't even a need to fiddle with the bits! The code above can be replaced by the following two lines (assuming m_sPositionName is an appropriately initialized array):

    pWidget->nCurrentPosition = DIO_Input; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Thank you, Mr. Obvious.
    Not only obvious, but probably incorrect too. All of the systems of this type I've worked with expose eight input values as bits of a byte. The low four bits correspond to the output of the wheel sensor, but the other four could be used for anything. This is a classic case of Muphry's Law.
    pWidget->nCurrentPosition = DIO_Input & 15; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Better?

    This is what happens when you try to refactor for no reason, the bit clearing never reaches the array lookup. We should ensure the bits are actually cleared with a failsafe loop:

    while(pWidget->nCurrentPosition & (-1^15)) pWidget->nCurrentPosition &= 15; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Obviously this code should have a unit test.

  • nerfer (unregistered) in reply to Adam
    Adam:
    This is what happens when you try to refactor for no reason, the bit clearing never reaches the array lookup. We should ensure the bits are actually cleared with a failsafe loop:

    while(pWidget->nCurrentPosition & (-1^15)) pWidget->nCurrentPosition &= 15; pWidget->sCurrentPosition = pWidget->m_sPositionName[DIO_Input];

    Obviously this code should have a unit test.

    Oh yeah, like that's totally readable. -1^15? nice bit of obfuscation there.

    pWidget->nCurrentPosition = DIO_Input & 0x0F; pWidget->sCurrentPosition = pWidget->m_sPositionName[pWidget->nCurrentPosition];

    Gotta admit, this was a nice WTF, good to get away from obscure (to me) database abuses and the like, and it was blindingly obviously bad code.

  • Guidoogle (unregistered)

    a4d9966d-5ea2-4eb0-8eb1-59c0caba38f8 Mon premier est un animal qui vit dans les bois . Mon deuxième est un oiseau. Mon troisième est un oiseau noir qui vole les objets brillants. Mon quatrième est un poisson. Mon tout est un animal. => a09f662a-7cfd-4c0d-a10c-149299846762

  • BigBadAssLou (unregistered) in reply to Silent Penguin
    Silent Penguin:
    Thats what the line
    Position = 1000*bit3 + 100*bit2 + 10*bit1 + bit0;
    is for silly!

    What I am REALLY impressed with is that the poor schmuck ... errrr ... programmer ... knew (or guessed) the correct associativity of the operators. Had this expression had dozens of pairs of parentheses, it would really look like code from our company. Just imagine:

    Position = ((1000*bit3) + (100*bit2)) + ((10*bit1) + (bit0));

    We have plenty of smarta**es here who would prefer to abstract their code away from bits and bytes if they could. I had the honor (or horror) of working with them.

    Need to go take a shower now and scrub hard .... "unclean, unclean!"

  • BleedingEyes (unregistered)

    I worked with a fellow student in a research lab a few years back. Data acquisition was all in c, so he decided he would learn c. A sudoku solver seemed like the most natural exercise. I shouldn't be too harsh because he was obviously new to c, but this was his approach: He stored the state of certain numbers being possible or not in a 9x9 int array. So obviously each bit mask was actually a decimal number. To work with the information, he had a number of helper routines that would use a lot of floating point logarithms, integer casts, and subtraction to work out the nature of the bit mask. There was another set of routines that used exponentiation (10^x) to put 1's (actually 1.0's, to be precise) in the proper decimal place and modify it. I tried explaining how much effort a proper bit mask would save. I got the non-committal answer, "Yeah, I'm sure there's a better way to do things, but this seems to work." Hard to argue with that.

  • BleedingEyes (unregistered) in reply to BigBadAssLou

    Then there's the Spartan approach of taking for granted the fact that, as long as everyone takes the time to learn the order of operations, there will be no confusion. If I recall correctly, Numerical Recipes advocates this. Away from the obfuscated c contest, I've not seen anything this heinous in the wild, but the Wikipedia page has some nice gems like:

    e = a < d ? a++ : a = d

Leave a comment on “Decimal Binary”

Log In or post as a guest

Replying to comment #350937:

« Return to Article