• Andrew (unregistered) in reply to BIG ASS MONKEY
    BIG ASS MONKEY:
    Spectre:
    Mog:
    But... wait... A char doesn't have to be 1 byte right?

    It does, sorry.

    The Japanese might disagree with you there.

    Also, the Java char type must be 2-byte Unicode. So, a zero character is stored as the number 48 decimal in a 2-byte integer.

    The numbers 0 to 9 are the codes 48+n, n in [0..9]. The hex letters A to F are 65+(k-11), k in [11..15]. This is how any language converts digits to char encodings.

  • Aisukurimu (unregistered) in reply to Andrew
    Andrew:
    BIG ASS MONKEY:
    Spectre:
    Mog:
    But... wait... A char doesn't have to be 1 byte right?

    It does, sorry.

    The Japanese might disagree with you there.

    Also, the Java char type must be 2-byte Unicode. So, a zero character is stored as the number 48 decimal in a 2-byte integer.

    The numbers 0 to 9 are the codes 48+n, n in [0..9]. The hex letters A to F are 65+(k-11), k in [11..15]. This is how any language converts digits to char encodings.

    Except not all japanese (kanji) characters are included in original unicode 16-bit range. UTF-16 would work, using 2x16 bits. Mostly needed for names, as far as I know. My ex-girlfriend couldn't write her name correctly with 16-bit unicode, she had to write the "sound" instead.

  • noname (unregistered) in reply to Zecc
    Zecc:
    case 16:
   return "F";

    Ummm... yeah.

  • Gordon (unregistered)

    I'm surprised nobody's commented on it, but my favorite part is:

      /**
   * The number of hexadecimal characters per byte.
   */
  public static final int NUMBER_OF_HEXADECIMAL_CHARACTERS_PER_BYTE = 2;

    I'm sure glad that comment is there, because otherwise who would have guessed that NUMBER_OF_HEXADECIMAL_CHARACTERS_PER_BYTE is supposed to represent the number of hexadecimal characters per byte?

  • Da' Man (unregistered) in reply to Bisqwit
    Bisqwit:
    *("0123456789ABCDEF" + ((bit1 << 3) | (bit2 << 2) | (bit3 << 1) | bit4))
    "0123456789ABCDEF"[bit1*8+bit2*4+bit3*2+bit4]
    I just remembered why I never came to really like this "C" thing.
  • Da' Man (unregistered) in reply to Serpardum
    Serpardum:
    I once wrote a function in C to convert from any base (up to 36) to any base (up to 36) which had .. what was it, 25 lines or so?
    I once wrote a function to convert numbers from any base to any other base.

    It made incredibly sophisticated use of "sin()" and "tan()". And it was in AmigaBasic.

    And my only excuse is that I was yound and innocent (just 16 y.o.) at that time. Well, I'm still kind of young... ;-)

  • Fuzz! (unregistered) in reply to Da' Man
    Da' Man:
    Serpardum:
    I once wrote a function in C to convert from any base (up to 36) to any base (up to 36) which had .. what was it, 25 lines or so?
    I once wrote a function to convert numbers from any base to any other base.

    It made incredibly sophisticated use of "sin()" and "tan()". And it was in AmigaBasic.

    And my only excuse is that I was yound and innocent (just 16 y.o.) at that time. Well, I'm still kind of young... ;-)

    not sure where sin and tan would come into simple integer maths..

    usage: ToAnyBase(100, new char[] {'0', '1'}) // == "1100100"

    you can give any alphabet you like, so you can encode numbers into the numeric alphabet 'NeRdLiNgEr' (which is actually base 10 so not a great example) as long as two characters don't repeat themselves - that would make the value impossible to decode back into an int... such validation should be added to the function but i CBF'd.

    string ToAnyBase(int value, char[] alphabet)
{
    if (value < 0)
        throw new ArgumentOutOfRangeException();
    if (alphabet == null || alphabet.Length < 2)
        throw new ArgumentOutOfRangeException();

    Stack<char> output = new Stack<char>();
    do
    {
        output.Push(alphabet[value % alphabet.Length]);
        value /= alphabet.Length;
    } while (value > 0);

    return new String(output.ToArray());
}
  • Ron (unregistered)

    This person was obviously educated in the USA.

  • Mykelyk (unregistered)

    In c the obvious one-linear: ((a?"DF9B":"5713")+!!c)[2*!b]-!d

  • George (unregistered) in reply to Manos

    In some archaic architectures (eg. pdp10 and 704) a byte has 9 bits. but no one uses thoes archetectures anymore.

  • (cs) in reply to D0R
    D0R:
    But at least *their* version is easier to extend if hexadecimal suddenly gets a 17th character...
    Exactly. I find especially enlightened this part of the code: 
    public static final int NUMBER_OF_HEXADECIMAL_CHARACTERS_PER_BYTE = 2;
    to ensure compatibility, should the Universe reboot and the laws of mathematics be modified, in case the number of hex numbers per byte changes.
    Well, I'm presently writing test specs for an embedded system that includes the manifest constant 
    #define NUMBER_MS_PER_SECOND 1000
    ... and, because it's a test spec, and all calculations have to be spelled out, and because we also call an OS function called SysGetTicksPerSecond(), I end up writing ridiculous rubbish like 
    ticks = TIMEOUT_MS * SysGetTicksPerSecond() / NUMBER_MS_PER_SECOND
= 5000 * 2000 / 1000
= 10000
    ... over and over again. It's doing my head in.

    It's not that I object to being paid per line, which in a sense is how this is working out.

    It's just that, under the circumstances, I'd prefer the lines in question to be coke. And I don't even like the damn stuff.

  • perlo (unregistered) in reply to Roman
    Roman:
    Perl code examples plz? ;-)

    print [0..9,a..f]->[$bit18+$bit24+$bit32$bit4];

  • Joe Z (unregistered) in reply to rbonvall

    Gah... why do all of you cling to bit1 through bit4? They were extracted from the number already in their correct positions.

    headdesk

    If you want to avoid the cycle cost of sprintf() (and I've been in such situations believe it or not), why not something like this to convert a 32-bit number into a hex string?

    void int_to_hex(unsigned int x, char *buf)
{
    int i;
  
    buf[8] = 0;
    for (i = 7; i >= 0; i--)
    {
        buf[i] = (x & 0xF)["0123456789ABCDEF"];
        x >>= 4;
    }
}
  • Babak (unregistered)

    I think I wrote a lexical analyzer in that same manner for a compilers class back in college....I quickly learned the error of my ways.

  • mark (unregistered) in reply to NiceWTF
    NiceWTF:
    Sunday Ironfoot:
    [..] Well that would be my implementation. Probably a better /shorter way somewhere.

    In Java it can indeed be done in 1 line:

    public static String toHex(byte[] input) {
  return new BigInteger(input).toString(16); 
}

    writing one line of code that actually results in executing a thousand lines of code is no better than the op's solution...

  • mark (unregistered) in reply to iToad
    iToad:
    frustrati:
    brazzy:
    Actually, in C a byte does not necessarily have 8 bits. There is nothing in the least unusual about needing more than 2 hex digits to represent a byte.
    Actually, in C there is no "byte" data type

    Depends on the dialect of C. Some C compilers used for 8-bit microcontroller development may have both a "byte" data type and a "bit" data type. 8-bit processors may support either or both of these data types without having to pack and unpack larger data structures.

    "without having to pack and unpack larger data structures"

    you clearly have never looked at the asm output of the majority microcontroller C compilers

  • Grant (unregistered) in reply to blub

    Why separate the bits into individual bools just to recombine them? Try this:

    const char *nibbles = "0123456789ABCDEF"; char firstChar = nibbles[byteValue & 0xF]; char secondChar = nibbles[(byteValue>>4) & 0xF];

    Then just go through each byte as needed

  • Harald (unregistered) in reply to brazzy
    brazzy:
    Actually, in C a byte does not necessarily have 8 bits. There is nothing in the least unusual about needing more than 2 hex digits to represent a byte.
    Actually, to express the level of how much this statement hurts, I need many more than two hexadecimal digits. ;-)
  • (cs) in reply to The Fake WTF
    The Fake WTF:
    Bitwise shifts are faster than multiplication. Unless you assume that your compiler will only be used on settings which optimize constant multiples like that.

    If you want speed, you turn on optimization on the compiler. If you don't turn on optimization and worry about speed, you're wasting your time doing things the compiler could be doing.

  • Douglastab (unregistered)

    pharmacie en ligne fiable https://kamagraenligne.shop/# pharmacie en ligne

Leave a comment on “Classic WTF: To the Hexth Degree”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article