Bit representation of a float

Discussion in 'C Programming' started by Gary Baydo, Aug 15, 2007.

  1. Gary Baydo

    Gary Baydo Guest

    In an effort to write a simple rounding function, I wrote the following code
    out of
    curiosity. My question is, can I rely on the output to 'make sense'? As an
    added
    'exercise' I tried to write the code in a portable manner, not just for my
    box that
    uses 8-bit bytes and 4-byte floats.

    Comments and critiques are welcome. Thanks.

    /* display the binary representation of a float variable */
    #include <stdio.h>
    #include <limits.h>

    int main(void) {
    int i, j;
    float f, *pf;
    char *pc;

    f = 42; /* assign some arbitrary value */
    pf = &f;
    pc = (char *)pf;

    for (i = 0; i < sizeof(float); i++) {
    for (j = 0; j < CHAR_BIT; j++) {
    printf("%d", *pc & (1 << j) ? 1 : 0);
    fflush(stdout);
    }
    pc++;
    printf(" ");
    fflush(stdout);
    }

    return 0;
    }

    --
    Gary Baydo
    email: my initial and last name at mindspring.com
    Anyone can make mistakes, but only an idiot persists in his error.
    - Cicero
     
    Gary Baydo, Aug 15, 2007
    #1
    1. Advertisements

  2. Gary Baydo <> wrote:
    > In an effort to write a simple rounding function, I wrote the following code
    > out of curiosity. My question is, can I rely on the output to 'make sense'?
    > As an added 'exercise' I tried to write the code in a portable manner, not
    > just for my box that uses 8-bit bytes and 4-byte floats.
    > Comments and critiques are welcome. Thanks.


    > /* display the binary representation of a float variable */
    > #include <stdio.h>
    > #include <limits.h>


    > int main(void) {
    > int i, j;
    > float f, *pf;
    > char *pc;


    > f = 42; /* assign some arbitrary value */
    > pf = &f;
    > pc = (char *)pf;


    > for (i = 0; i < sizeof(float); i++) {
    > for (j = 0; j < CHAR_BIT; j++) {
    > printf("%d", *pc & (1 << j) ? 1 : 0);
    > fflush(stdout);
    > }
    > pc++;
    > printf(" ");
    > fflush(stdout);
    > }


    > return 0;
    > }


    Looks ok to me. Just that always flushing stdout seems a bit
    superfluous and if you want to output just a singe char using
    printf() is a bit of overkill. If you want to tighten it a bit
    (and you don't mind that f's value gets changed in the process)
    you could try:

    #include <stdio.h>
    #include <limits.h>

    int main( void ) {
    size_t i, j;
    float f = 42;
    unsigned char *pc = ( unsigned char * ) &f;

    for ( i = 0; i < sizeof f; pc++, i++ ) {
    for ( j = 0; j < CHAR_BIT; *pc >>= 1, j++ )
    putchar( ( *pc & 1 ) + '0' );
    putchar( ' ' );
    }

    putchar( '\n' );
    return 0;
    }
    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Aug 15, 2007
    #2
    1. Advertisements

  3. Jens Thoms Toerring said:

    <snip>

    > If you want to tighten it a bit
    > (and you don't mind that f's value gets changed in the process)
    > you could try:
    >
    > #include <stdio.h>
    > #include <limits.h>
    >
    > int main( void ) {
    > size_t i, j;
    > float f = 42;
    > unsigned char *pc = ( unsigned char * ) &f;
    >
    > for ( i = 0; i < sizeof f; pc++, i++ ) {
    > for ( j = 0; j < CHAR_BIT; *pc >>= 1, j++ )
    > putchar( ( *pc & 1 ) + '0' );


    Won't this put the bits the wrong way round?

    I suggest this instead:

    #include <stdio.h>
    #include <limits.h>

    void fprintbyte(FILE *fp, unsigned char n, int bits)
    {
    if(bits > 1)
    {
    fprintbyte(fp, n / 2, bits - 1);
    }
    putc((n & 1) + '0', fp);
    }

    void fprintbin(FILE *fp, void *vp, size_t len)
    {
    unsigned char *p = vp;
    while(len-- > 0)
    {
    fprintbyte(fp, *p++, CHAR_BIT);
    }
    putchar('\n'); /* clearly optional - adjust to taste */
    }

    int main(void)
    {
    long double ld = 42.0L;
    double d = 42.0;
    float f = 42.0F;
    fprintbin(stdout, &ld, sizeof ld);
    fprintbin(stdout, &d, sizeof d);
    fprintbin(stdout, &f, sizeof f);
    return 0;
    }

    On my system, the output is as follows:

    000000000000000000000000000000000000000000000000000000001010100000000100010000000000000001000000
    0000000000000000000000000000000000000000000000000100010101000000
    00000000000000000010100001000010

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Aug 15, 2007
    #3
  4. Richard Heathfield <> wrote:
    > Jens Thoms Toerring said:


    > <snip>


    > > If you want to tighten it a bit
    > > (and you don't mind that f's value gets changed in the process)
    > > you could try:
    > >
    > > #include <stdio.h>
    > > #include <limits.h>
    > >
    > > int main( void ) {
    > > size_t i, j;
    > > float f = 42;
    > > unsigned char *pc = ( unsigned char * ) &f;
    > >
    > > for ( i = 0; i < sizeof f; pc++, i++ ) {
    > > for ( j = 0; j < CHAR_BIT; *pc >>= 1, j++ )
    > > putchar( ( *pc & 1 ) + '0' );


    > Won't this put the bits the wrong way round?


    Well, that seemed to be the way the OP wanted it, least significant
    byte first and also least significant bit of each byte first.

    > I suggest this instead:


    > #include <stdio.h>
    > #include <limits.h>


    > void fprintbyte(FILE *fp, unsigned char n, int bits)
    > {
    > if(bits > 1)
    > {
    > fprintbyte(fp, n / 2, bits - 1);
    > }
    > putc((n & 1) + '0', fp);
    > }


    Recursion is fun but I probably wouldn't have used it in this
    situation;-)
    Regards; Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Aug 15, 2007
    #4
  5. Gary Baydo

    Richard Bos Guest

    "Gary Baydo" <> wrote:

    > In an effort to write a simple rounding function, I wrote the following code
    > out of curiosity. My question is, can I rely on the output to 'make sense'?


    Yes and no. See below.

    > As an added 'exercise' I tried to write the code in a portable manner, not
    > just for my box that uses 8-bit bytes and 4-byte floats.
    >
    > Comments and critiques are welcome. Thanks.
    >
    > /* display the binary representation of a float variable */
    > #include <stdio.h>
    > #include <limits.h>
    >
    > int main(void) {
    > int i, j;
    > float f, *pf;
    > char *pc;


    This should really be an unsigned char *.

    > f = 42; /* assign some arbitrary value */
    > pf = &f;
    > pc = (char *)pf;


    You don't need this double assignment; directly writing

    pc = (unsigned char *)&f;

    works just as well.

    > for (i = 0; i < sizeof(float); i++) {
    > for (j = 0; j < CHAR_BIT; j++) {
    > printf("%d", *pc & (1 << j) ? 1 : 0);
    > fflush(stdout);
    > }
    > pc++;
    > printf(" ");
    > fflush(stdout);
    > }


    You really do not need to fflush(stdout) after every single character.
    Doing it at the end of the entire loop should work just fine.

    You can rely on the output making _some_ sense, since the representation
    of floating point numbers must follow certain patterns as laid out in
    the Standard. You must have a fixed base and precision for each floating
    point type, and each FPN must have a sign, an exponent, and a fixed
    number of significand digits. However, how these numbers are represented
    in the underlying bits is not specified by the Standard, so you may not
    immediately recognise the pattern; but it must be there. (Most likely,
    probably, you will see IEC 60559 numbers. But that's not required.)

    Richard
     
    Richard Bos, Aug 15, 2007
    #5
  6. In article <4all.nl>,
    Richard Bos <> wrote:

    >You can rely on the output making _some_ sense, since the representation
    >of floating point numbers must follow certain patterns as laid out in
    >the Standard. You must have a fixed base and precision for each floating
    >point type, and each FPN must have a sign, an exponent, and a fixed
    >number of significand digits. However, how these numbers are represented
    >in the underlying bits is not specified by the Standard, so you may not
    >immediately recognise the pattern; but it must be there.



    I have just reviewed the C89 wording on it, and I'm not -convinced-
    that the precision must be fixed.

    FLT_RADIX must be a constant. Everything else in <float.h> is
    allowed to be non-constant expressions ("non-constant" is specifically
    mentioned.)

    FLT_MANT_DIG and kin are defined in C89 as

    number of decimal digits, q, such that any floating point number
    with q decimal digits can be rounded into a floating-point
    number with p radix b digits and back again without change
    to the q decimal digits

    It seems to me that if you had some kind of variable precision, then
    FLT_MANT_DIG and kin could be the worst-case numbers, with the
    possibility that you might get noticably more accuracy on some values.

    The whole s/b/e/p/f[k] floating point model is just that, a -model-,
    an abstraction, that need not necessarily be followed internally as long
    as you can get the necessary behaviours to work out.


    Not that I can see any good reason to implement anything else -- not even
    any half-baked reason. But if someone implemented a format that (say)
    had variable amounts of significant storage and padded the rest
    [e.g., some kind of toaster where 1/32 was the finest resolution needed
    for 99% of the calculations], then I don't know that that'd be ruled out.
    --
    "It is important to remember that when it comes to law, computers
    never make copies, only human beings make copies. Computers are given
    commands, not permission. Only people can be given permission."
    -- Brad Templeton
     
    Walter Roberson, Aug 15, 2007
    #6
  7. Gary Baydo

    pete Guest

    Gary Baydo wrote:
    >
    > In an effort to write a simple rounding function, I wrote the following code
    > out of
    > curiosity. My question is, can I rely on the output to 'make sense'? As an
    > added
    > 'exercise' I tried to write the code in a portable manner, not just for my
    > box that
    > uses 8-bit bytes and 4-byte floats.
    >
    > Comments and critiques are welcome. Thanks.
    >
    > /* display the binary representation of a float variable */
    > #include <stdio.h>
    > #include <limits.h>
    >
    > int main(void) {
    > int i, j;
    > float f, *pf;
    > char *pc;
    >
    > f = 42; /* assign some arbitrary value */
    > pf = &f;
    > pc = (char *)pf;
    >
    > for (i = 0; i < sizeof(float); i++) {
    > for (j = 0; j < CHAR_BIT; j++) {
    > printf("%d", *pc & (1 << j) ? 1 : 0);
    > fflush(stdout);
    > }
    > pc++;
    > printf(" ");
    > fflush(stdout);
    > }
    >
    > return 0;
    > }


    I wrote a function named bitstr, for that purpose.
    bitstr works with any type, not just floats.

    Here's what the output looks like on my machine:

    /* BEGIN output from bitstr.c */

    0.333333 = 00111110101010101010101010101011
    0.666667 = 00111111001010101010101010101011
    1.333333 = 00111111101010101010101010101011
    2.666667 = 01000000001010101010101010101011
    5.333333 = 01000000101010101010101010101011
    10.666667 = 01000001001010101010101010101011
    21.333334 = 01000001101010101010101010101011
    42.666668 = 01000010001010101010101010101011

    /* END output from bitstr.c */


    /* BEGIN bitstr.c */

    #include <limits.h>
    #include <stdio.h>

    #define STRING "%15f = %s\n"
    #define E_TYPE float
    #define INITIAL (1.0f / 3)
    #define FINAL 50
    #define INC(E) ((E) *= 2)

    typedef E_TYPE e_type;

    void bitstr(char *str, const void *obj, size_t n);

    int main(void)
    {
    e_type e;
    char ebits[CHAR_BIT * sizeof e + 1];

    puts("\n/* BEGIN output from bitstr.c */\n");
    for (e = INITIAL; FINAL >= e; INC(e)) {
    bitstr(ebits, &e, sizeof e);
    printf(STRING, e, ebits);
    }
    puts("\n/* END output from bitstr.c */");
    return 0;
    }

    void bitstr(char *str, const void *obj, size_t n)
    {
    unsigned mask;
    const unsigned char *byte = obj;

    while (n-- != 0) {
    mask = ((unsigned char)-1 >> 1) + 1;
    do {
    *str++ = (char)(mask & byte[n] ? '1' : '0');
    mask >>= 1;
    } while (mask != 0);
    }
    *str = '\0';
    }

    /* END bitstr.c */


    --
    pete
     
    pete, Aug 15, 2007
    #7
  8. On 2007-08-15 12:58, Richard Heathfield <> wrote:
    > Jens Thoms Toerring said:
    >> int main( void ) {
    >> size_t i, j;
    >> float f = 42;
    >> unsigned char *pc = ( unsigned char * ) &f;
    >>
    >> for ( i = 0; i < sizeof f; pc++, i++ ) {
    >> for ( j = 0; j < CHAR_BIT; *pc >>= 1, j++ )
    >> putchar( ( *pc & 1 ) + '0' );

    >
    > Won't this put the bits the wrong way round?


    On a little-endian system, it's consistent.


    > I suggest this instead:
    >
    > #include <stdio.h>
    > #include <limits.h>
    >
    > void fprintbyte(FILE *fp, unsigned char n, int bits)
    > {
    > if(bits > 1)
    > {
    > fprintbyte(fp, n / 2, bits - 1);
    > }
    > putc((n & 1) + '0', fp);
    > }
    >
    > void fprintbin(FILE *fp, void *vp, size_t len)
    > {
    > unsigned char *p = vp;
    > while(len-- > 0)
    > {
    > fprintbyte(fp, *p++, CHAR_BIT);
    > }
    > putchar('\n'); /* clearly optional - adjust to taste */
    > }


    This is consistent on a big-endian system. But on a little-endian system
    (like yours) the output is inconsistent: Bytes are output least
    significant first, but bits within the bytes are output most significant
    first, which means that adjacent bits in memory aren't adjacent in the
    output:

    > On my system, the output is as follows:
    >
    > 0000000000000000000000000000000000000000000000000100010101000000

    | . | . | . | . | . | . EEEE. SEEEEEEE
    0000 1000000
    3210 0987654

    I've marked the sign bit and the the exponent here. You notice that
    the sign bit appears to be in middle of the bitstring and the exponent
    bits 3 and 4 don't appear to be adjacent. This is hard to read.

    Here is my version (which does a bit more than just print bits):

    static void printdouble(double f) {
    union {
    doubleint i;
    double f;
    } u;
    doubleint e;
    doubleint m;

    u.f = f;

    printf(doubleformat, f);
    printf(": ");
    printf("%c ", (u.i & SIGN_DBL) ? '-' : '+');
    u.i &= ~SIGN_DBL;
    e = u.i >> MANT_DBL;
    printbinary(e, BITS_DBL-1-MANT_DBL);

    m = (u.i & (((doubleint)1 << MANT_DBL) - 1));
    if (e == 0) {
    printf(" [0.]");
    } else {
    printf(" [1.]");
    }
    printbinary(m, MANT_DBL);
    printf("\n");
    }

    (doubleint is typedef'ed to unsigned long or unsigned long long
    (uint64_t didn't exist in 1998) and various constants are hard-coded for
    IEEE-754 numbers - the whole program is at
    http://www.hjp.at/programs/ieeefloat/ if somebody's interested)

    hp


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Aug 18, 2007
    #8
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bd
    Replies:
    0
    Views:
    722
  2. Replies:
    3
    Views:
    1,958
    Timothy Bendfelt
    Jan 19, 2007
  3. k3n3dy
    Replies:
    15
    Views:
    1,066
    dan2online
    Apr 20, 2006
  4. Replies:
    9
    Views:
    1,168
    Juha Nieminen
    Aug 22, 2007
  5. Carsten Fuchs
    Replies:
    45
    Views:
    1,756
    James Kanze
    Oct 8, 2009
Loading...

Share This Page