Bit representation of a float

G

Gary Baydo

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;
}
 
J

Jens Thoms Toerring

Gary Baydo said:
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
 
R

Richard Heathfield

Jens Thoms Toerring said:

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
 
J

Jens Thoms Toerring

Richard Heathfield said:
Jens Thoms Toerring said:
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
 
R

Richard Bos

Gary Baydo said:
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
 
W

Walter Roberson

Richard Bos said:
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.
 
P

pete

Gary said:
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 */
 
P

Peter J. Holzer

Jens Thoms Toerring said:

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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,997
Messages
2,570,239
Members
46,827
Latest member
DMUK_Beginner

Latest Threads

Top