hakossem
asked on
float structure
I need to know the float structure (float representation in the memory).
I wrote a small program to do so but I don't understand the output.
Can someone help
(I'm using gcc under Linux with a 80x86)
program:
#include <stdio.h>
typedef union
{
float f;
char c[4];
} fc;
void print(fc nb)
{
printf("%f\t%03d %03d %03d %03d\n", nb.f, nb.c[0], nb.c[1], nb.c[2], nb.c[3]);
}
main()
{
fc a;
printf("float size: %d\n", sizeof(float));
a.f=1; print(a);
a.f=2; print(a);
a.f=3; print(a);
a.f=10; print(a);
a.f=20; print(a);
a.f=100;print(a);
a.f=-1; print(a);
a.f=-2; print(a);
a.f=1; print(a);
}
output:
float size: 4
1.000000 000 000 -128 063
2.000000 000 000 000 064
3.000000 000 000 064 064
10.000000 000 000 032 065
20.000000 000 000 -96 065
100.000000 000 000 -56 066
-1.000000 000 000 -128 -65
-2.000000 000 000 000 -64
1.000000 000 000 -128 063
I wrote a small program to do so but I don't understand the output.
Can someone help
(I'm using gcc under Linux with a 80x86)
program:
#include <stdio.h>
typedef union
{
float f;
char c[4];
} fc;
void print(fc nb)
{
printf("%f\t%03d %03d %03d %03d\n", nb.f, nb.c[0], nb.c[1], nb.c[2], nb.c[3]);
}
main()
{
fc a;
printf("float size: %d\n", sizeof(float));
a.f=1; print(a);
a.f=2; print(a);
a.f=3; print(a);
a.f=10; print(a);
a.f=20; print(a);
a.f=100;print(a);
a.f=-1; print(a);
a.f=-2; print(a);
a.f=1; print(a);
}
output:
float size: 4
1.000000 000 000 -128 063
2.000000 000 000 000 064
3.000000 000 000 064 064
10.000000 000 000 032 065
20.000000 000 000 -96 065
100.000000 000 000 -56 066
-1.000000 000 000 -128 -65
-2.000000 000 000 000 -64
1.000000 000 000 -128 063
ASKER
fc is an union not a structure.
a.c and a.f occuppe the same memory place so when I initialize a.f I change the content of a.c
a.c and a.f occuppe the same memory place so when I initialize a.f I change the content of a.c
Your program is absolutely correct if
the sizeof(float) is 4. I think that is
true in Linux.
I think the problem is in printing :
Try this :
void print(fc nb)
{
printf("%f\t%03d %03d %03d %03d\n", nb.f, (int)nb.c[0], (int) nb.c[1], (int) nb.c[2], (int) nb.c[3]);
}
You are trying to print integer but sending the characters. I think by casting this will solve your problem.
Give me the output. I will certainly solve this.
the sizeof(float) is 4. I think that is
true in Linux.
I think the problem is in printing :
Try this :
void print(fc nb)
{
printf("%f\t%03d %03d %03d %03d\n", nb.f, (int)nb.c[0], (int) nb.c[1], (int) nb.c[2], (int) nb.c[3]);
}
You are trying to print integer but sending the characters. I think by casting this will solve your problem.
Give me the output. I will certainly solve this.
basant, I think hakossem is just trying to find out, how the value is stored in memory.
hakossem, perhaps this helps:
It is problaly stored according to the IEEE standard for 4-byte real numbers:
sign bit, 8-bit exponent, 23-bit mantissa.
There is an assumed leading 1 in the mantissa that is not stored in memory, so the mantissa is actually 24 bits, even though only 23 bits are stored.
The exponent is biased by half of the possible value. This means you subtract this bias from the stored exponent to get the actual exponent. If the stored exponent is less than the bias, it is actually a negative exponent.
The exponent is biased by 127 for 4-byte reals.
The exponent is powers of two.
Remember that Intel cpu's stores the bytes in reverse order in memory, so in your example, c[0] is bit 24-31, c[1] is bit 16-23, c[2] is bit 8-15 and c[3] is bit 0-7.
The sign bit is the first bit of c[3], as you can se is the only difference between 1, 2 and -1, -2.
1: The 1-bit for the mantissa is not stored, so it is all 0-bits. The exponent is zero, so because of the bias, the stored value is 127 or 7 1-bits. The first is stored as the first bit of c[2] giving it the value of -128. The rest are stored in c[3], giving the value of 63.
2: Now the exponent is 1, storing 128, or one 1-bit, which gives the value of 64.
3: As 2, except the value of the mantissa is now 3, storing one 1-bit, which gives the value of 64 in c[2]
etc.
hakossem, perhaps this helps:
It is problaly stored according to the IEEE standard for 4-byte real numbers:
sign bit, 8-bit exponent, 23-bit mantissa.
There is an assumed leading 1 in the mantissa that is not stored in memory, so the mantissa is actually 24 bits, even though only 23 bits are stored.
The exponent is biased by half of the possible value. This means you subtract this bias from the stored exponent to get the actual exponent. If the stored exponent is less than the bias, it is actually a negative exponent.
The exponent is biased by 127 for 4-byte reals.
The exponent is powers of two.
Remember that Intel cpu's stores the bytes in reverse order in memory, so in your example, c[0] is bit 24-31, c[1] is bit 16-23, c[2] is bit 8-15 and c[3] is bit 0-7.
The sign bit is the first bit of c[3], as you can se is the only difference between 1, 2 and -1, -2.
1: The 1-bit for the mantissa is not stored, so it is all 0-bits. The exponent is zero, so because of the bias, the stored value is 127 or 7 1-bits. The first is stored as the first bit of c[2] giving it the value of -128. The rest are stored in c[3], giving the value of 63.
2: Now the exponent is 1, storing 128, or one 1-bit, which gives the value of 64.
3: As 2, except the value of the mantissa is now 3, storing one 1-bit, which gives the value of 64 in c[2]
etc.
I agree to hustch. Probably printing will be OK.
ASKER
it doesn't need casting
hustch post your comment as an answer it works fine.
If you know the description of double too I'll enjoy you to send it too.
hustch post your comment as an answer it works fine.
If you know the description of double too I'll enjoy you to send it too.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
where did u initialized the string a.c?
i think it prints the crapy data in a.c and the correct data for a.f [as inserted...]
ma habeaya?
whats the problem?
adi