By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,948 Members | 663 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,948 IT Pros & Developers. It's quick & easy.

Bit representation of a float

P: n/a
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
Aug 15 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Gary Baydo <gb****@mindspring.comwrote:
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 ___ jt@toerring.de
\__________________________ http://toerring.de
Aug 15 '07 #2

P: n/a
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:

00000000000000000000000000000000000000000000000000 0000001010100000000100010000000000000001000000
00000000000000000000000000000000000000000000000001 00010101000000
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
Aug 15 '07 #3

P: n/a
"Gary Baydo" <gb****@mindspring.comwrote:
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
Aug 15 '07 #4

P: n/a
Richard Heathfield <rj*@see.sig.invalidwrote:
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 ___ jt@toerring.de
\__________________________ http://toerring.de
Aug 15 '07 #5

P: n/a
In article <46*****************@news.xs4all.nl>,
Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:
>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.his
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
Aug 15 '07 #6

P: n/a
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
Aug 15 '07 #7

P: n/a
On 2007-08-15 12:58, Richard Heathfield <rj*@see.sig.invalidwrote:
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:

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 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.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Aug 18 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.