-1

Can someone explain the step by step procedure to do the above?

Hermes
  • 2,828
  • 2
  • 14
  • 34
Midhlaj Zain
  • 9
  • 1
  • Not only is it unclear what you are asking, I **think** a recently posted question asks something very similar: https://stackoverflow.com/questions/54947861/32-bit-ieee-754-single-precision-floating-point-to-hexadecimal . A class-mate? – Rudy Velthuis Mar 01 '19 at 21:21
  • Possible duplicate of [32-bit IEEE 754 single precision floating point to hexadecimal](https://stackoverflow.com/questions/54947861/32-bit-ieee-754-single-precision-floating-point-to-hexadecimal) – Peter Cordes Mar 02 '19 at 03:49

1 Answers1

1

The following is for IEEE-754 basic 32-bit binary floating-point with round-to-nearest-ties-to-even:

  1. Start with input number x.
  2. If x is 0, produce 0x00000000 (for 0) and stop.
  3. Set e to 0.
  4. Set s to 0 if 0 ≤ x or 1 if x < 0, and set x to |x|.
  5. Repeat while 2 ≤ x: Divide x by 2 and add 1 to e.
  6. Repeat while x < 1: Multiply x by 2 and subtract 1 from e.
  7. Multiply x by 223.
  8. If e < −126, divide x by 2−126−e and set e to −126.
  9. If the fraction part of x is less than ½, change it to 0.
  10. If the fraction part of x is greater than ½, change it 0 and add 1 to f.
  11. If the fraction part of x is ½, change it to 0. Then, if x is odd, add 1 to x.
  12. Divide x by 223.
  13. If 2 ≤ x, divide f by 2 and add 1 to e.
  14. If 127 < e:
    • If s is 1, produce 0xff800000 (for −∞) and stop.
    • Otherwise, produce 0x7f800000 (for +∞) and stop.
  15. If 1 ≤ x:
    • Add 127 to e and subtract 1 from x.
    • Otherwise, set e to 0.
  16. Produce s•231 + e•223 + x•223 in hexadecimal and stop.

The above is from memory and untested, so it should be double-checked.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
  • If you're printing `0x7f800000` for +inf, is this supposed to be an algorithm for printing the binary32 bit-pattern in hex *without* type-punning it to integer? So not a hex-float or something. – Peter Cordes Mar 05 '19 at 07:37
  • And BTW, I think you missed `-0.0` in your special cases at the top. I guess move step 2. lower down until after decoding *s* from a compare result, and then if `x == 0.0` (rather than *is* 0) produce `s<<31`. – Peter Cordes Mar 05 '19 at 07:37
  • @PeterCordes: The input is a real number, so −0 is 0. – Eric Postpischil Mar 05 '19 at 07:38
  • 1
    @PeterCordes: In the same vein, the output is the IEEE-754 encoding for the result of converting the input to the nearest representable value. In one of the recent duplicates, the author said it was to prepare for a test, so I figure the input is a real number, not a `float` in C or something. I should have been more explicit about the input and output, but I should not have written this anyway—I have other things I need to be doing. I just could not resist putting it out there. – Eric Postpischil Mar 05 '19 at 07:44
  • Oh, so you're not trying to preserve +-0.0 in your hex output? I would have tried to preserve what you can (with functions like `signbit()`). NaN payloads are obviously harder. But ok if you're pretending the input is a real number, not an IEEE754 value like this question asks for, then that makes some sense. – Peter Cordes Mar 05 '19 at 07:48