Velocity Reviews > Bit representation of a float

# Bit representation of a float

Gary Baydo
Guest
Posts: n/a

 08-15-2007
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
'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

Jens Thoms Toerring
Guest
Posts: n/a

 08-15-2007
Gary Baydo <(E-Mail Removed)> 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://www.velocityreviews.com/forums/(E-Mail Removed)
\__________________________ http://toerring.de

Richard Heathfield
Guest
Posts: n/a

 08-15-2007
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?

#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:

00000000000000000000000000000000000000000000000000 0000001010100000000100010000000000000001000000
00000000000000000000000000000000000000000000000001 00010101000000
00000000000000000010100001000010

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999

Jens Thoms Toerring
Guest
Posts: n/a

 08-15-2007
Richard Heathfield <(E-Mail Removed)> 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.

> #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 ___ (E-Mail Removed)
\__________________________ http://toerring.de

Richard Bos
Guest
Posts: n/a

 08-15-2007
"Gary Baydo" <(E-Mail Removed)> 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

Walter Roberson
Guest
Posts: n/a

 08-15-2007
In article <(E-Mail Removed)4all.nl>,
Richard Bos <(E-Mail Removed)> 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)
[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."

pete
Guest
Posts: n/a

 08-15-2007
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
> '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)
{
const unsigned char *byte = obj;

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

/* END bitstr.c */

--
pete

Peter J. Holzer
Guest
Posts: n/a

 08-18-2007
On 2007-08-15 12:58, Richard Heathfield <(E-Mail Removed)> 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.

>
> #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:
>
> 00000000000000000000000000000000000000000000000001 00010101000000

| . | . | . | . | . | . 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 199 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.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"