IEEE float number !? 
Author Message
 IEEE float number !?

Hello all,
  There is a program got from internet.

  static unsigned long jflone = 0x3f800000;
  static unsigned long jflmsk = 0x007fffff;

  idum = 1664525L*idum + 1013904223L;
  itemp = (jflone | (jflmsk & idum)); //(*)
  rd = (*(float *)&itemp)-1.0;

  The author said that program transformed the idum into a value
between 0.0 and 1.0
  where jflone and jflmsk is the IEEE representation for 32-bit
floating-point numbers.
  Does anyone understand the program? How to understand (*)?

Thanks in advance.



Wed, 24 Nov 2004 01:52:49 GMT  
 IEEE float number !?
It just so happens I've been fooling around with IEEE-754
representations, trying to understand a funky quick math
library I've recently received.

There's a neat little web page here at queens college:

http://babbage.cs.qc.edu/courses/cs341/IEEE-754hex32.html

that will probably help you with this.

Are we to assume that idum is an unsigned long 0-0xffffffff?

HTH

Quote:

> Hello all,
>   There is a program got from internet.

>   static unsigned long jflone = 0x3f800000;
>   static unsigned long jflmsk = 0x007fffff;

>   idum = 1664525L*idum + 1013904223L;
>   itemp = (jflone | (jflmsk & idum)); //(*)
>   rd = (*(float *)&itemp)-1.0;

>   The author said that program transformed the idum into a value
> between 0.0 and 1.0
>   where jflone and jflmsk is the IEEE representation for 32-bit
> floating-point numbers.
>   Does anyone understand the program? How to understand (*)?

> Thanks in advance.



Wed, 24 Nov 2004 03:33:21 GMT  
 IEEE float number !?
The line
idum = 1664525L * idum + 1013904223L;
is just a random number generator using the Linear Congruential Method.

By masking
jflmsk & idum
we get a 23-bit (random) number.

The IEEE representation for 32-bit floating-point numbers has the layout
seeeeeeeefffffffffffffffffffffff (8 e's and 23 f's).
s is the sign bit, the eight e's is the biased exponent, and the
twenty-three f's is the fraction.
The exponent bias is 127. For 0 < e < 255, the number represented is
(-1)**s * 2**(e - 127) * 1.f where ** means exponentiation.
If s is 0 and e is 127, then the number is 1.f, i.e. a number in the range
[1.0, 2.0).

Now in hex 127 is 0x7f. Putting it into the floating-point format we get
0x3f800000.

So, the line
unsigned long itemp = (jflone | (jflmsk & idum)); //(*)
creates a floating-point number with biased exponent 127 and fraction the
lower 23 bits of idum, i.e. a random floating-point number in
the range [1.0, 2.0).
The reason for using the range [1.0, 2.0) is because the IEEE floating-point
numbers are uniform distributed in that interval.
The last line subtracts 1 to get a result in the range [0.0, 1.0).

Carsten Hansen

----------

Quote:

> Hello all,
>   There is a program got from internet.

>   static unsigned long jflone = 0x3f800000;
>   static unsigned long jflmsk = 0x007fffff;

>   idum = 1664525L*idum + 1013904223L;
>   itemp = (jflone | (jflmsk & idum)); //(*)
>   rd = (*(float *)&itemp)-1.0;

>   The author said that program transformed the idum into a value
> between 0.0 and 1.0
>   where jflone and jflmsk is the IEEE representation for 32-bit
> floating-point numbers.
>   Does anyone understand the program? How to understand (*)?

> Thanks in advance.



Thu, 25 Nov 2004 01:42:04 GMT  
 IEEE float number !?
On 7 Jun, in article


Quote:
>Hello all,
>  There is a program got from internet.

>  static unsigned long jflone = 0x3f800000;
>  static unsigned long jflmsk = 0x007fffff;

>  idum = 1664525L*idum + 1013904223L;
>  itemp = (jflone | (jflmsk & idum)); //(*)
>  rd = (*(float *)&itemp)-1.0;

1.0F would make more sense here.

Strictly speaking the code has undefined behaviour on various counts.
If we assume that unsigned long and float have representations where the
code above makes sense then there is still undefined behaviour due to
access itemp (which presumably has type unsigned long) using a float
lvalue. This eliminates that problem:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void)
{
    static const unsigned long jflone = 0x3f800000;
    static const unsigned long jflmsk = 0x007fffff;

    int i;

    for (i = 0; i < 100; i++) {
        unsigned long idum = rand();
        unsigned long itemp;
        float rd;

        idum = 1664525L*idum + 1013904223L;
        itemp = (jflone | (jflmsk & idum));

        memcpy(&rd, &itemp, sizeof rd);
        rd--;

        printf("%f\n", rd);
    }

    return 0;

Quote:
}
>  The author said that program transformed the idum into a value
>between 0.0 and 1.0
>  where jflone and jflmsk is the IEEE representation for 32-bit
>floating-point numbers.
>  Does anyone understand the program? How to understand (*)?

It creates the float representation of a number of the form
+1.xxxxxxxxxxxxxxxxxxxxxxx * 2^^0 which produces a value in the range
1 <= value < 2. It then subtracts 1 from this producing a result in the
range  0 <= result < 1

--
-----------------------------------------


-----------------------------------------



Thu, 25 Nov 2004 18:40:20 GMT  
 IEEE float number !?

Quote:

> The line
> idum = 1664525L * idum + 1013904223L;
> is just a random number generator using the Linear Congruential Method.

> By masking
> jflmsk & idum
> we get a 23-bit (random) number.

> The IEEE representation for 32-bit floating-point numbers has the layout
> seeeeeeeefffffffffffffffffffffff (8 e's and 23 f's).
> s is the sign bit, the eight e's is the biased exponent, and the
> twenty-three f's is the fraction.
> The exponent bias is 127. For 0 < e < 255, the number represented is
> (-1)**s * 2**(e - 127) * 1.f where ** means exponentiation.
> If s is 0 and e is 127, then the number is 1.f, i.e. a number in the range
> [1.0, 2.0).

> Now in hex 127 is 0x7f. Putting it into the floating-point format we get
> 0x3f800000.

> So, the line
> unsigned long itemp = (jflone | (jflmsk & idum)); //(*)
> creates a floating-point number with biased exponent 127 and fraction the
> lower 23 bits of idum, i.e. a random floating-point number in
> the range [1.0, 2.0).
> The reason for using the range [1.0, 2.0) is because the IEEE floating-point
> numbers are uniform distributed in that interval.
> The last line subtracts 1 to get a result in the range [0.0, 1.0).

> Carsten Hansen

> ----------


> > Hello all,
> >   There is a program got from internet.

> >   static unsigned long jflone = 0x3f800000;
> >   static unsigned long jflmsk = 0x007fffff;

> >   idum = 1664525L*idum + 1013904223L;
> >   itemp = (jflone | (jflmsk & idum)); //(*)
> >   rd = (*(float *)&itemp)-1.0;

> >   The author said that program transformed the idum into a value
> > between 0.0 and 1.0
> >   where jflone and jflmsk is the IEEE representation for 32-bit
> > floating-point numbers.
> >   Does anyone understand the program? How to understand (*)?

> > Thanks in advance.

Carsten, your explanation of float is slightly flawed, I think. I spent
more that a little time on this. Consider..

/*
   All I know about IEEE floating point, by Joe Wright.
   This information was obtained by inspection of the operation of
   DJGPP (GNU C 2.7.2.1) on my x86 PC.  I have no IEEE documentation.
   The Intel architecture (DPMI) is 32-bit and little endian.

   (64-bit double)

            6         5         4         3         2         1

3210987654321098765432109876543210987654321098765432109876543210
         -   1-bit sign (1 == negative)
          -----------  11-bit exponent (unsigned)
   53-bit mantissa
-----------------------------------------------------

   (32-bit float)

          3         2         1
         10987654321098765432109876543210
         -   1-bit sign (1 == negative)
          --------   8-bit exponent (unsigned)
   24-bit mant   ------------------------

   Floating point numbers are fractions (less than 1) expressed in the
   mantissa raised to a power (of 2) expressed in the exponent.

   The mantissa consists of bits to the right of a binary point.  The
   value of the mantissa is always positive.

   A note about binary fractions:  .1 == 1/2, .01 == 1/4, .001 == 1/8,
   etc.  The value 5 would be .101 (5/8) raised to the third power of 2
(8)
   such that 5/8 * 8 == 5.

   Normalization:  This is the final step of FP ops which shifts the
   (non-zero) mantissa left until its high-bit (b23) is 1, decrementing
the
   exponent accordingly.  Because we know that this high bit will always
   be one, we don't have to reserve space for it in the float object.
   Its place is actually occupied by the low order bit of the exponent.

       255  129   Inf     (Mantissa == .10000000 00000000 00000000)
       254  128   FLT_MAX (Mantissa == .11111111 11111111 11111111)
       253  127
       252  126
      ---------
       128    2
       127    1
       126    0
       125   -1
       124   -2
      ---------
         3 -123
         2 -124
         1 -125   FLT_MIN (Mantissa == .10000000 00000000 00000000)
         0 -126   Zero    (Mantissa == .10000000 00000000 00000000)

   The 8-bit exponent is stored with a range of 255..0.  A bias of 126
   is subtracted from the stored value to arrive at the mathematical
   value of the exponent (See table above).

       2047  1025    Inf       (Mantissa == .10000 00000000 ...
00000000)
       2046  1024    DBL_MAX   (Mantissa == .11111 11111111 ...
11111111)
       2045  1023
       2044  1022
       ----------
       1024     2
       1023     1
       1022     0
       1021    -1
       1020    -2
       ----------
          3 -1019
          2 -1020
          1 -1021    DBL_MIN   (Mantissa == .10000 00000000 ...
00000000)
          0 -1022    Zero      (Mantissa == .10000 00000000 ...
00000000)

   Double Precision Floating Point (double) is similar but wider, with
   an 11-bit exponent and a 53-bit mantissa.  The exponent range is
   2047..0 and the bias is 1022.

   There are some 'special' representations:
   Inf:  All bits of the exponent are 1 and all mantissa bits 0.
   NaN:  All bits of the exponent are 1 and any mantissa bit 1.
         NaN generates a floating point exception on my machine.
   Zero: All bits are 0.
   Sub-Normal: All exponent bits are 0 and any mantissa bit 1.
         A sub-normal float converted to double will be normalized.

*/
0x3f800000
00111111 10000000 00000000 00000000
Exp = 127 (1)
  00000001
Man =   .10000000 00000000 00000000
1.00000000e+00

0x007fffff
00000000 01111111 11111111 11111111
Exp = 0 (-126)
  10000010
Man =   .11111111 11111111 11111111
1.17549421e-38

--

"Everything should be made as simple as possible, but not simpler."
                    --- Albert Einstein ---



Thu, 25 Nov 2004 23:21:55 GMT  
 IEEE float number !?

----------

Quote:


>> The line
>> idum = 1664525L * idum + 1013904223L;
>> is just a random number generator using the Linear Congruential Method.

>> By masking
>> jflmsk & idum
>> we get a 23-bit (random) number.

>> The IEEE representation for 32-bit floating-point numbers has the layout
>> seeeeeeeefffffffffffffffffffffff (8 e's and 23 f's).
>> s is the sign bit, the eight e's is the biased exponent, and the
>> twenty-three f's is the fraction.
>> The exponent bias is 127. For 0 < e < 255, the number represented is
>> (-1)**s * 2**(e - 127) * 1.f where ** means exponentiation.
>> If s is 0 and e is 127, then the number is 1.f, i.e. a number in the range
>> [1.0, 2.0).

>> Now in hex 127 is 0x7f. Putting it into the floating-point format we get
>> 0x3f800000.

>> So, the line
>> unsigned long itemp = (jflone | (jflmsk & idum)); //(*)
>> creates a floating-point number with biased exponent 127 and fraction the
>> lower 23 bits of idum, i.e. a random floating-point number in
>> the range [1.0, 2.0).
>> The reason for using the range [1.0, 2.0) is because the IEEE floating-point
>> numbers are uniform distributed in that interval.
>> The last line subtracts 1 to get a result in the range [0.0, 1.0).

>> Carsten Hansen

>> ----------


>> > Hello all,
>> >   There is a program got from internet.

>> >   static unsigned long jflone = 0x3f800000;
>> >   static unsigned long jflmsk = 0x007fffff;

>> >   idum = 1664525L*idum + 1013904223L;
>> >   itemp = (jflone | (jflmsk & idum)); //(*)
>> >   rd = (*(float *)&itemp)-1.0;

>> >   The author said that program transformed the idum into a value
>> > between 0.0 and 1.0
>> >   where jflone and jflmsk is the IEEE representation for 32-bit
>> > floating-point numbers.
>> >   Does anyone understand the program? How to understand (*)?

>> > Thanks in advance.

> Carsten, your explanation of float is slightly flawed, I think. I spent
> more that a little time on this. Consider..

> /*
>    All I know about IEEE floating point, by Joe Wright.
>    This information was obtained by inspection of the operation of
>    DJGPP (GNU C 2.7.2.1) on my x86 PC.  I have no IEEE documentation.
>    The Intel architecture (DPMI) is 32-bit and little endian.

>    (64-bit double)

>             6         5         4         3         2         1

> 3210987654321098765432109876543210987654321098765432109876543210
>          -   1-bit sign (1 == negative)
>           -----------  11-bit exponent (unsigned)
>    53-bit mantissa
> -----------------------------------------------------

>    (32-bit float)

>           3         2         1
>          10987654321098765432109876543210
>          -   1-bit sign (1 == negative)
>           --------   8-bit exponent (unsigned)
>    24-bit mant   ------------------------

>    Floating point numbers are fractions (less than 1) expressed in the
>    mantissa raised to a power (of 2) expressed in the exponent.

>    The mantissa consists of bits to the right of a binary point.  The
>    value of the mantissa is always positive.

>    A note about binary fractions:  .1 == 1/2, .01 == 1/4, .001 == 1/8,
>    etc.  The value 5 would be .101 (5/8) raised to the third power of 2
> (8)
>    such that 5/8 * 8 == 5.

>    Normalization:  This is the final step of FP ops which shifts the
>    (non-zero) mantissa left until its high-bit (b23) is 1, decrementing
> the
>    exponent accordingly.  Because we know that this high bit will always
>    be one, we don't have to reserve space for it in the float object.
>    Its place is actually occupied by the low order bit of the exponent.

>        255  129   Inf     (Mantissa == .10000000 00000000 00000000)
>        254  128   FLT_MAX (Mantissa == .11111111 11111111 11111111)
>        253  127
>        252  126
>       ---------
>        128    2
>        127    1
>        126    0
>        125   -1
>        124   -2
>       ---------
>          3 -123
>          2 -124
>          1 -125   FLT_MIN (Mantissa == .10000000 00000000 00000000)
>          0 -126   Zero    (Mantissa == .10000000 00000000 00000000)

>    The 8-bit exponent is stored with a range of 255..0.  A bias of 126
>    is subtracted from the stored value to arrive at the mathematical
>    value of the exponent (See table above).

>        2047  1025    Inf       (Mantissa == .10000 00000000 ...
> 00000000)
>        2046  1024    DBL_MAX   (Mantissa == .11111 11111111 ...
> 11111111)
>        2045  1023
>        2044  1022
>        ----------
>        1024     2
>        1023     1
>        1022     0
>        1021    -1
>        1020    -2
>        ----------
>           3 -1019
>           2 -1020
>           1 -1021    DBL_MIN   (Mantissa == .10000 00000000 ...
> 00000000)
>           0 -1022    Zero      (Mantissa == .10000 00000000 ...
> 00000000)

>    Double Precision Floating Point (double) is similar but wider, with
>    an 11-bit exponent and a 53-bit mantissa.  The exponent range is
>    2047..0 and the bias is 1022.

>    There are some 'special' representations:
>    Inf:  All bits of the exponent are 1 and all mantissa bits 0.
>    NaN:  All bits of the exponent are 1 and any mantissa bit 1.
>          NaN generates a floating point exception on my machine.
>    Zero: All bits are 0.
>    Sub-Normal: All exponent bits are 0 and any mantissa bit 1.
>          A sub-normal float converted to double will be normalized.

> */
> 0x3f800000
> 00111111 10000000 00000000 00000000
> Exp = 127 (1)
>   00000001
> Man =   .10000000 00000000 00000000
> 1.00000000e+00

> 0x007fffff
> 00000000 01111111 11111111 11111111
> Exp = 0 (-126)
>   10000010
> Man =   .11111111 11111111 11111111
> 1.17549421e-38

> --

> "Everything should be made as simple as possible, but not simpler."
>                     --- Albert Einstein ---

------------

I think it is you being wrong. The bias for the exponent for single
precision floating-point numbers is 127.

First that is what the Standard says. Yes, I have a copy of the ANSI/IEEE
Std 754-1985 Standard for Binary Floating-Point Arithmetic.
On page 9 there is a table specifying the exponent bias. For Single it is
127. For Double it is 1023.
Moreover, my description follows what is in paragraph 3.2.1 about the Single
format.
Another reference is Hennessy and Patterson, Computer Architecture: A
Quantitative Approach, Second Edition, p. A-16.

Second, take the number 0x3f800000. Here the sign is 0. The biased exponent
is 127. The fractional part is 0. According to the formula I gave this
number is
 (-1)**s * 2**(e - 127) * 1.f  = 1.0
I would suggest you enter 0x3f800000 into memory and read it back as a
single precision floating-point number and print it out (you can use the
original posters program). The answer will be 1.0.

Carsten Hansen



Fri, 26 Nov 2004 05:18:33 GMT  
 IEEE float number !?

Quote:
>         unsigned long idum = rand();
>         idum = 1664525L*idum + 1013904223L;

For the record, idum = idum * a + c; is recursive method to get "random"
values.. calling rand() to initialize it, then to do the * a + c is
pointless.

Quote:
>         memcpy(&rd, &itemp, sizeof rd);
>         rd--;

If we get here, we could just aswell write:

int v = rand() % n;
float fv = (float)v / (float)n;

.. the point of the code was to be fast, and "clever" with 754 format, even
if a bit non-portable, non-topical here as it wouldn't be "C" this this
group knows it. ;-)



Sat, 27 Nov 2004 23:15:26 GMT  
 IEEE float number !?
Quote:

> ----------



> >> The line
> >> idum = 1664525L * idum + 1013904223L;
> >> is just a random number generator using the Linear Congruential Method.

> >> By masking
> >> jflmsk & idum
> >> we get a 23-bit (random) number.

> >> The IEEE representation for 32-bit floating-point numbers has the layout
> >> seeeeeeeefffffffffffffffffffffff (8 e's and 23 f's).
> >> s is the sign bit, the eight e's is the biased exponent, and the
> >> twenty-three f's is the fraction.
> >> The exponent bias is 127. For 0 < e < 255, the number represented is
> >> (-1)**s * 2**(e - 127) * 1.f where ** means exponentiation.
> >> If s is 0 and e is 127, then the number is 1.f, i.e. a number in the range
> >> [1.0, 2.0).

> >> Now in hex 127 is 0x7f. Putting it into the floating-point format we get
> >> 0x3f800000.

> >> So, the line
> >> unsigned long itemp = (jflone | (jflmsk & idum)); //(*)
> >> creates a floating-point number with biased exponent 127 and fraction the
> >> lower 23 bits of idum, i.e. a random floating-point number in
> >> the range [1.0, 2.0).
> >> The reason for using the range [1.0, 2.0) is because the IEEE floating-point
> >> numbers are uniform distributed in that interval.
> >> The last line subtracts 1 to get a result in the range [0.0, 1.0).

> >> Carsten Hansen

> >> ----------


> >> > Hello all,
> >> >   There is a program got from internet.

> >> >   static unsigned long jflone = 0x3f800000;
> >> >   static unsigned long jflmsk = 0x007fffff;

> >> >   idum = 1664525L*idum + 1013904223L;
> >> >   itemp = (jflone | (jflmsk & idum)); //(*)
> >> >   rd = (*(float *)&itemp)-1.0;

> >> >   The author said that program transformed the idum into a value
> >> > between 0.0 and 1.0
> >> >   where jflone and jflmsk is the IEEE representation for 32-bit
> >> > floating-point numbers.
> >> >   Does anyone understand the program? How to understand (*)?

> >> > Thanks in advance.

> > Carsten, your explanation of float is slightly flawed, I think. I spent
> > more that a little time on this. Consider..

> > /*
> >    All I know about IEEE floating point, by Joe Wright.
> >    This information was obtained by inspection of the operation of
> >    DJGPP (GNU C 2.7.2.1) on my x86 PC.  I have no IEEE documentation.
> >    The Intel architecture (DPMI) is 32-bit and little endian.

> >    (64-bit double)

> >             6         5         4         3         2         1

> > 3210987654321098765432109876543210987654321098765432109876543210
> >          -   1-bit sign (1 == negative)
> >           -----------  11-bit exponent (unsigned)
> >    53-bit mantissa
> > -----------------------------------------------------

> >    (32-bit float)

> >           3         2         1
> >          10987654321098765432109876543210
> >          -   1-bit sign (1 == negative)
> >           --------   8-bit exponent (unsigned)
> >    24-bit mant   ------------------------

> >    Floating point numbers are fractions (less than 1) expressed in the
> >    mantissa raised to a power (of 2) expressed in the exponent.

> >    The mantissa consists of bits to the right of a binary point.  The
> >    value of the mantissa is always positive.

> >    A note about binary fractions:  .1 == 1/2, .01 == 1/4, .001 == 1/8,
> >    etc.  The value 5 would be .101 (5/8) raised to the third power of 2
> > (8)
> >    such that 5/8 * 8 == 5.

> >    Normalization:  This is the final step of FP ops which shifts the
> >    (non-zero) mantissa left until its high-bit (b23) is 1, decrementing
> > the
> >    exponent accordingly.  Because we know that this high bit will always
> >    be one, we don't have to reserve space for it in the float object.
> >    Its place is actually occupied by the low order bit of the exponent.

> >        255  129   Inf     (Mantissa == .10000000 00000000 00000000)
> >        254  128   FLT_MAX (Mantissa == .11111111 11111111 11111111)
> >        253  127
> >        252  126
> >       ---------
> >        128    2
> >        127    1
> >        126    0
> >        125   -1
> >        124   -2
> >       ---------
> >          3 -123
> >          2 -124
> >          1 -125   FLT_MIN (Mantissa == .10000000 00000000 00000000)
> >          0 -126   Zero    (Mantissa == .10000000 00000000 00000000)

> >    The 8-bit exponent is stored with a range of 255..0.  A bias of 126
> >    is subtracted from the stored value to arrive at the mathematical
> >    value of the exponent (See table above).

> >        2047  1025    Inf       (Mantissa == .10000 00000000 ...
> > 00000000)
> >        2046  1024    DBL_MAX   (Mantissa == .11111 11111111 ...
> > 11111111)
> >        2045  1023
> >        2044  1022
> >        ----------
> >        1024     2
> >        1023     1
> >        1022     0
> >        1021    -1
> >        1020    -2
> >        ----------
> >           3 -1019
> >           2 -1020
> >           1 -1021    DBL_MIN   (Mantissa == .10000 00000000 ...
> > 00000000)
> >           0 -1022    Zero      (Mantissa == .10000 00000000 ...
> > 00000000)

> >    Double Precision Floating Point (double) is similar but wider, with
> >    an 11-bit exponent and a 53-bit mantissa.  The exponent range is
> >    2047..0 and the bias is 1022.

> >    There are some 'special' representations:
> >    Inf:  All bits of the exponent are 1 and all mantissa bits 0.
> >    NaN:  All bits of the exponent are 1 and any mantissa bit 1.
> >          NaN generates a floating point exception on my machine.
> >    Zero: All bits are 0.
> >    Sub-Normal: All exponent bits are 0 and any mantissa bit 1.
> >          A sub-normal float converted to double will be normalized.

> > */
> > 0x3f800000
> > 00111111 10000000 00000000 00000000
> > Exp = 127 (1)
> >   00000001
> > Man =   .10000000 00000000 00000000
> > 1.00000000e+00

> > 0x007fffff
> > 00000000 01111111 11111111 11111111
> > Exp = 0 (-126)
> >   10000010
> > Man =   .11111111 11111111 11111111
> > 1.17549421e-38

> > --

> > "Everything should be made as simple as possible, but not simpler."
> >                     --- Albert Einstein ---

> ------------

> I think it is you being wrong. The bias for the exponent for single
> precision floating-point numbers is 127.

> First that is what the Standard says. Yes, I have a copy of the ANSI/IEEE
> Std 754-1985 Standard for Binary Floating-Point Arithmetic.
> On page 9 there is a table specifying the exponent bias. For Single it is
> 127. For Double it is 1023.
> Moreover, my description follows what is in paragraph 3.2.1 about the Single
> format.
> Another reference is Hennessy and Patterson, Computer Architecture: A
> Quantitative Approach, Second Edition, p. A-16.

> Second, take the number 0x3f800000. Here the sign is 0. The biased exponent
> is 127. The fractional part is 0. According to the formula I gave this
> number is
>  (-1)**s * 2**(e - 127) * 1.f  = 1.0
> I would suggest you enter 0x3f800000 into memory and read it back as a
> single precision floating-point number and print it out (you can use the
> original posters program). The answer will be 1.0.

Let me apologize for calling you wrong. I'm sorry. It would seem the
difference between your explanation and mine is placement of the
imaginary binary point. You place it to the right of the implicit 1 bit
at b23 and mine places it to the left. That accounts for your bias of
127 and mine of 126.

--

"Everything should be made as simple as possible, but not simpler."
                    --- Albert Einstein ---



Fri, 03 Dec 2004 00:10:06 GMT  
 IEEE float number !?

Quote:

> It just so happens I've been fooling around with IEEE-754
> representations, trying to understand a funky quick math
> library I've recently received.

> There's a neat little web page here at queens college:

> http://babbage.cs.qc.edu/courses/cs341/IEEE-754hex32.html

> that will probably help you with this.

> Are we to assume that idum is an unsigned long 0-0xffffffff?

> HTH

Hey, that's cool. The original poster may also be interested
to see James Carr's informative site on IEEE-754:

http://www.scri.fsu.edu/~jac/MAD3401/Backgrnd/ieee.html
--
Randy Yates
DSP Engineer, Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA



Sat, 11 Dec 2004 19:35:27 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. IEEE conversion: bytes into floating point number...

2. Format of IEEE floating point number?

3. IEEE conversion: bytes into floating point number...

4. Converting Microsoft Floating Point type to the IEEE floating

5. Microsoft Float to IEEE float format

6. IEEE-754 floats in C

7. convert IEEE 754 single-precision 32-bit float to its corresponding bits

8. IEEE Floating Point Representation

9. Convert IBM Floating Point to IEEE 754

10. How to check bit patterns for IEEE float and double

11. IEEE floating point question

12. ieee floating point

 

 
Powered by phpBB® Forum Software