Can someone explain this output for me?

[PolteRGeisT]

Okay.. math.h is confusing the hell out of me


#include <math.h>
#include <iostream>

using namespace std;

int main(void)
{
cout << (__extension__ 0x1.0p255f) << endl;
cout << (0x1.0p255f) << endl;

return 0;
}


What the heck is p ?? and what does __extension__ do?

[Strogian]

That is output? That looks like source code to me.. What does it have to do with math.h, btw? :)

[PolteRGeisT]

please run it.

[sharth]

i compiled that using iostream.h without math.h and it worked the same. I'm thinking that it is doing some sort of hex conversion or something.

[sharth]

perhaps inf == infinity

[sharth]

GCC uses the __extension__ attribute when using the -ansi flag to avoid warnings in headers with GCC extensions. This is mostly used in glibc with function declartions using long long.

[PolteRGeisT]

both cout and printf output inf when I do that,(printf needs it to be %f). Is it a console thing? and what does the p in the number mean? That code doesn't compile on MS compilers...

[dchidelf]

I'm not sure of all the details as I have an old gcc compiler that does not support hex floating point constants, but that is what you are seeing.

f tells the compiler the number is a float
the p is the multiplier.
so your number would appear to be:
1.0 x (2^255) ... which is quite large
apparently it is infinity. :)

IEEE floating point numbers have reserved values.
There are positive and negative infinities INF,
as well as a not-a-number value NaN.

0x1.0p255f is apparently the hex constant for infinity.

[dchidelf]

Out of curiousity I just wanted to see if that hex value was the ieee infinity so I checked it in C


float d = 1.0;
float x = 1;
int i;
for(i=0;i<255;x*=2,++i); /* x=2^255 */
d *= x;
fprintf(stderr,"%f\n", d);


This produces the output "Inf".
Changing d to 0.0 produces the output "NaN".

[bwkaz]

According to the IEEE 754 floating-point representation standard, IIRC anyway, the bit sequence:

000...0111...1

is infinity.

The number of 0's and 1's depend on the type of floating-point number you're talking about (I believe that float's take 24 0's and 8 1's, but I'm not positive on that -- it does look likely from your posted example, though). doubles, since they're twice as long total (64 bits rather than 32), take more bits in each, but I don't remember for sure how the extra 32 bits get split up (I think it's 3 for the exponent, which means 29 for the mantissa, making it 53 and 11, but don't quote me on that).

long doubles take 80 bits total, but they do represent the 1 bit at the beginning explicitly (doubles and singles (floats) don't, the 1 bit is implied).

You can probably find out about the binary encoding for IEEE 754 by Googling on that phrase. Anything you find should have the bit sequences for Inf and NaN, too.

[dchidelf]

It looks like doubles do get an extra 3 bits for the exponent.
At least from these tests:


$ perl -e 'printf("%f\n",1*(2**2047));'
Inf
$ perl -e 'printf("%f\n",-1*(2**2047));'
-Inf
$ perl -e 'printf("%f\n",0*(2**2047));'
NaN


What I won't do to avoid pulling my computer architecture books off the shelf. :) But alas, here they come:

for double prec. numbers:
1111111111110000...00000 = -INF
0111111111110000...00000 = INF
011111111111[ non zero ] = NaN

[bwkaz]

So the exponent is stored before the mantissa?

Guess I though the mantissa was stored first -- oops. ;) Oh well, not that it matters much.

Oh, right, it would have to be, to make it easier to compare numbers without interpreting them -- you can just make believe they're normal binary numbers, since the one with the bigger exponent will be bigger, unless it's negative. Just like normal binary numbers.