Introduction

Converting an IEEE 754 double to a decimal string looks simple until you require the result to be correct, round-trippable, and short. The bit layout is easy to decode, but producing the shortest decimal string that parses back to the same binary floating-point value is a specialized algorithmic problem, which is why mature runtimes use algorithms such as Dragon4, Grisu, or Ryu rather than a naive repeated-division implementation.

Start With the IEEE 754 Layout

A double-precision IEEE 754 value has:

• 1 sign bit
• 11 exponent bits
• 52 fraction bits

In normalized form, the value is interpreted as:

• sign
• times significand
• times a power of two

A simple bit extraction example in C looks like this:

1#include <stdint.h>
2#include <string.h>
3#include <stdio.h>
4
5void inspect_double(double x) {
6    uint64_t bits;
7    memcpy(&bits, &x, sizeof(bits));
8
9    uint64_t sign = bits >> 63;
10    uint64_t exponent = (bits >> 52) & 0x7FF;
11    uint64_t fraction = bits & ((1ULL << 52) - 1);
12
13    printf("sign=%llu exponent=%llu fraction=%llu\n",
14           (unsigned long long)sign,
15           (unsigned long long)exponent,
16           (unsigned long long)fraction);
17}

This tells you what the bits are, but it does not yet solve the decimal-formatting problem.

Handle Special Values First

A complete algorithm starts by handling the special cases separately:

• exponent all ones and fraction zero means infinity
• exponent all ones and fraction nonzero means NaN
• exponent zero and fraction zero means signed zero
• exponent zero and fraction nonzero means subnormal number

These branches are straightforward compared with ordinary finite formatting.

1if (exponent == 0x7FF) {
2    if (fraction == 0) {
3        /* inf or -inf */
4    } else {
5        /* nan */
6    }
7}

Special-case handling matters because these values do not follow the normal implicit-leading-one rule.

Why Naive Decimal Conversion Fails

A tempting approach is:

1. reconstruct the binary floating-point value as a rational number
2. repeatedly multiply or divide to get decimal digits
3. stop when the output looks accurate enough

The problem is that "accurate enough" is not a rigorous stopping rule. Correct conversion needs to respect rounding boundaries so that:

• the printed string parses back to the exact same double
• the string is not longer than necessary
• halfway cases round correctly

This is where simple homemade algorithms usually go wrong.

The Real Problem: Shortest Correct Round-Trip String

Modern float-to-string algorithms solve a more exact task:

• compute the decimal interval that rounds back to the original double
• generate the shortest decimal inside that interval
• format it efficiently

Ryu is famous because it computes this quickly using integer arithmetic and precomputed powers. Grisu is very fast but may need fallback logic. Dragon4 is older, flexible, and correct, but often more complex.

The key point is that serious float formatting algorithms do not merely "print many digits." They reason about the decimal interval that preserves the original binary value.

A Practical Strategy: Use the Runtime Implementation

Unless you are writing a language runtime, serializer, or numeric library, the right answer is usually to use the standard library formatter.

For example, in Java:

1public class Main {
2    public static void main(String[] args) {
3        double x = 0.1;
4        System.out.println(Double.toString(x));
5    }
6}

In Python:

x = 0.1
print(str(x))

Those runtime implementations already use high-quality float-formatting logic. Reimplementing them from scratch is rarely worth it unless the algorithm itself is your project.

If You Must Implement It

If your actual task is to implement the conversion algorithm, the high-level structure is:

1. decode sign, exponent, and fraction
2. classify special cases
3. normalize the significand and binary exponent
4. compute decimal boundaries for the exact rounding interval
5. generate digits inside that interval
6. choose fixed or scientific notation formatting

The difficult part is step four and step five. That is where Ryu, Grisu, and Dragon4 differ.

So the honest engineering advice is:

• use a published algorithm
• or reuse a known-good implementation
• do not invent the rounding logic ad hoc

Common Pitfalls

• Extracting the IEEE 754 fields correctly but then using a naive decimal-generation loop still produces incorrect or overlong strings.
• Ignoring NaN, infinity, signed zero, and subnormal values leaves the implementation incomplete.
• Printing too many digits may be correct but ugly; printing too few can break round-tripping.
• Assuming decimal formatting is just base conversion misses the need for exact rounding boundaries.
• Reimplementing this from scratch without a known algorithm such as Ryu, Grisu, or Dragon4 is a common path to subtle numeric bugs.

Summary

• Decoding the bits of a double is easy compared with formatting it correctly as decimal.
• The hard part is generating the shortest decimal string that round-trips back to the same IEEE 754 value.
• Special values such as NaN, infinity, signed zero, and subnormals must be handled explicitly.
• Production-quality runtimes use dedicated algorithms such as Ryu, Grisu, or Dragon4.
• If you are not writing a runtime or numeric library, use the language's built-in double formatting instead of implementing the algorithm yourself.