Floating Point Converter

A floating point converter is a tool that takes a human-readable decimal number, such as 3.14 or -0.5, and translates it into the binary format that processors actually store in memory. That binary format is governed by the IEEE 754 standard, the international specification that defines how nearly every modern CPU, GPU, and programming language runtime represents numbers with decimal places.

Most floating point converters support three precision formats: 16-bit half precision, 32-bit single precision, and 64-bit double precision. Each format allocates a different number of bits for storing the number, which determines both its range and how precisely it can represent a given value.

The reason this conversion matters is that the value the converter stores is not always identical to the value you typed. Binary arithmetic cannot represent every decimal fraction exactly, which means the stored result may differ slightly from the input. This difference, called a representation error, is not a bug in the converter. It is a property of the binary floating point format itself.

How Does the IEEE 754 Standard Define the Structure of a Floating Point Number?

The IEEE Standard for Floating-Point Arithmetic, first published in 1985 and most recently updated in 2019, defines how binary floating point numbers are structured, stored, and processed. It was created by the Institute of Electrical and Electronics Engineers to solve the problem of incompatible floating point implementations across different hardware platforms. Before the standard, the same decimal number might be stored differently on an Intel processor than on an IBM mainframe, making portable numerical software nearly impossible to write reliably.

The standard specifies that every floating point number is divided into three fields: a sign field, an exponent field, and a mantissa field. The number and purpose of bits in each field depend on the precision format being used. The table below shows the structure for the four IEEE 754 binary formats.

What Are the Three Bit Fields That Make Up an IEEE 754 Floating Point Number?

Every IEEE 754 floating point number is composed of exactly three fields, arranged from the most significant bit to the least significant bit: sign, exponent, and mantissa.

The sign bit occupies the leftmost position. A value of 0 means the number is positive. A value of 1 means it is negative. This single bit determines the overall sign of the number, regardless of the values in the other two fields.

The biased exponent comes next. It stores the power of two used to scale the significand. Rather than storing the exponent as a signed integer, IEEE 754 adds a fixed offset called the bias so that the exponent can be stored and compared as an unsigned integer. This simplifies the hardware required to compare and sort floating point values.

The mantissa, also called the significand or fraction field, occupies the remaining bits. It stores the fractional digits of the number after normalisation. In normalised numbers, the leading binary digit before the point is always 1 and is never stored explicitly. This is the hidden bit, and it gives one extra bit of free precision.

What Does the Sign Bit in an IEEE 754 Floating Point Number Actually Control?

In a 32-bit floating point number, bit 31 is the sign bit. When it is 0, the number is positive. When it is 1, the number is negative. Consider the values 6.625 and -6.625. Their bit patterns are identical in every field except bit 31.

+6.625 (hex 0x40D40000):  0  10000001  10101000000000000000000

-6.625 (hex 0xC0D40000):  1  10000001  10101000000000000000000

IEEE 754 also defines two representations of zero. Positive zero has all bits set to 0 (0x00000000). Negative zero has only the sign bit set to 1 (0x80000000). These two values compare as equal in any standard comparison, but they produce different bit patterns and can behave differently in edge cases involving division by zero or certain mathematical functions.

How Does the Biased Exponent in IEEE 754 Store Negative Powers Without a Second Sign Bit?

The stored exponent is not the raw power of two. It is the true exponent with the bias added to it. The formula is:

Stored exponent  =  True exponent  +  Bias

The bias values are 127 for 32-bit, 1023 for 64-bit, 15 for 16-bit, and 16383 for 128-bit. Using a bias instead of a signed exponent means the exponent field can be treated as a plain unsigned integer by the hardware. This allows two floating point numbers to be compared by magnitude using a single unsigned integer comparison of their exponent fields, with no special handling for negative exponents.

As a worked example, take the number 6.625. Its normalised form is 1.10101 x 2^2, so the true exponent is 2. The stored exponent for 32-bit is 2 + 127 = 129, which in 8-bit binary is 10000001.

A stored exponent of all zeros (0) and a stored exponent of all ones (255 in 32-bit) are reserved for special values and are handled differently from ordinary exponents.

What Is the Mantissa in IEEE 754 and Why Is the Leading 1 Always Implied but Never Stored?

The mantissa holds the fractional precision of the number. To understand why the leading 1 is never stored, consider how normalised scientific notation works. In decimal, we write 6.625 x 10^0 rather than 0.6625 x 10^1 because the leading digit before the point is always non-zero. In binary, the equivalent rule means the leading digit before the point is always 1, because binary only has two digits and a normalised number cannot have a leading 0.

Since the leading binary digit is always 1, storing it provides no new information. Dropping it frees up one bit, which is used to store an extra digit of mantissa precision instead. This is the hidden bit, or implied bit.

For 6.625, the full binary significance is 1.10101. The stored mantissa strips the leading 1 and pads to 23 bits: 10101000000000000000000. The effective precision is 24 bits even though only 23 are stored.

Subnormal numbers are the one exception. When the exponent field is all zeros, the implied leading digit is 0 rather than 1, which allows very small values close to zero to be represented with reduced precision instead of rounding to zero abruptly.

What Are the Differences Between 16-bit, 32-bit, 64-bit, and 128-bit Floating Point Precision Formats?

Each IEEE 754 format makes a different tradeoff between memory usage, range, and precision. The right choice depends on the application.

Choosing the wrong format causes real problems. Storing a value of 70,000 in half precision produces positive Infinity because 65,504 is the maximum. Using single precision for GPS coordinates, which require at least 8 significant digits for sub-metre accuracy, produces positional errors that compound in navigation calculations.

When Is Half Precision (16-bit) Floating Point Accurate Enough and When Does It Silently Lose Data?

Half precision stores 10 mantissa bits, giving 11 bits of effective precision and approximately 3 significant decimal digits. Values within the range of 0 to 65,504 that do not require more than 3 significant digits convert and store correctly. This makes half precision suitable for neural network weights during inference, GPU vertex coordinates, and normalised image colour channels in the range of 0 to 1.

The format fails silently when values exceed 65,504, which rounds to positive Infinity, or when more than 3 significant digits are needed. The value 1234.5, for example, may be stored as 1234 or 1236 because the mantissa cannot represent the difference. The minimum positive normalised value is approximately 6.1 x 10^-5, so very small values below this threshold become subnormal and lose further precision.

Why Do Developers Switch from Single Precision to Double Precision and What Precision Does Each Guarantee?

Single precision guarantees approximately 7 significant decimal digits. Double precision guarantees approximately 15 to 16. The concrete decision rule is: if the calculation requires more than 6 or 7 reliable decimal places, use double precision.

Practical cases where single precision is insufficient include GPS coordinates (where 8 or more significant digits determine sub-metre accuracy), cumulative financial totals, and physics simulations where small errors in each step accumulate over thousands of iterations. The classic test is 0.1 + 0.2. In both formats the result is not exactly 0.3, but the error in double precision is roughly 10,000 times smaller than in single precision.

Double precision uses 8 bytes rather than 4. In graphics pipelines and machine learning, where bandwidth and memory capacity are the primary constraints, single precision is the standard and switching to double would halve the throughput without improving most outputs.

How Do You Convert a Positive Decimal Number to IEEE 754 32-bit Floating Point Format Step by Step?

This section uses 6.625 as the example and works through all 8 steps for 32-bit single precision.

Step 1: Determine the sign bit.

6.625 is positive. Sign bit = 0.

Step 2: Convert the integer part to binary.

6 divided by 2 repeatedly: 6 = 4 + 2, so 6 in binary is 110.

Step 3: Convert the fractional part to binary using the multiply-by-2 method.

0.625 x 2 = 1.25  -->  bit = 1

0.25  x 2 = 0.50  -->  bit = 0

0.50  x 2 = 1.00  -->  bit = 1

Fractional binary = .101.

Step 4: Combine integer and fractional binary.

110.101

Step 5: Normalise.

Move the binary point left until exactly one non-zero digit sits before it:

1.10101 x 2^2

Step 6: Calculate the stored exponent.

True exponent = 2. Add the bias: 2 + 127 = 129.

129 in 8-bit binary = 10000001.

Step 7: Extract the mantissa.

Take the digits after the binary point in the normalised form (1.10101), drop the leading 1, and pad to 23 bits with trailing zeros:

10101000000000000000000

Step 8: Assemble the 32-bit string.

0  10000001  10101000000000000000000

Hexadecimal: 0x40D40000

How Do You Convert a Negative Decimal Number to IEEE 754 32-bit Floating Point Format Step by Step?

Converting a negative number follows the same 8 steps as a positive number, with one change: the sign bit is set to 1 in step 1. The absolute value of the number is used for all conversion steps from 2 to 7. This example uses -13.625.

Step 1: Determine the sign bit.

-13.625 is negative. Sign bit = 1.

Step 2: Convert the absolute integer part to binary.

13 in binary = 1101.

Step 3: Convert the fractional part to binary.

0.625 x 2 = 1.25  -->  bit = 1

0.25  x 2 = 0.50  -->  bit = 0

0.50  x 2 = 1.00  -->  bit = 1

Fractional binary = .101.

Step 4: Combine.

1101.101

Step 5: Normalise.

1.101101 x 2^3

Step 6: Calculate the stored exponent.

True exponent = 3. Add bias: 3 + 127 = 130. In 8-bit binary: 10000010.

Step 7: Extract the mantissa.

Digits after the point in 1.101101, padded to 23 bits:

10110100000000000000000

Step 8: Assemble.

1  10000010  10110100000000000000000

Hexadecimal: 0xC15A0000

How Do You Convert an IEEE 754 Binary String Back to Its Decimal Value?

Starting from the bit string 0  10000001  10101000000000000000000, which is the result from the positive example above, reversing the process takes 5 steps.

Step 1: Read the sign bit.

Bit 31 = 0. The number is positive.

Step 2: Read and decode the exponent.

10000001 in decimal = 129. True exponent = 129 - 127 = 2.

Step 3: Restore the hidden bit.

Stored mantissa: 10101000000000000000000. Restore the implied leading 1: 1.10101.

Step 4: Apply the exponent.

Move the binary point 2 places to the right: 110.101.

Step 5: Convert to decimal.

110.101  =  4 + 2 + 0.5 + 0.125  =  6.625

What Are the Largest and Smallest Numbers a 32-bit Floating Point Converter Can Accurately Represent?

When a value exceeds the maximum, the converter produces positive or negative Infinity. When a value is smaller than the minimum normalised value, it does not jump to zero. Instead, it becomes a subnormal number, storing the value with reduced precision. This gradual loss of precision is called gradual underflow, and it is a deliberate design in the IEEE 754 standard to avoid applications encountering a sudden cliff where small values vanish entirely.

The distance from Earth to the Andromeda Galaxy is approximately 2.4 x 10^22 metres, which fits comfortably within single precision range. However, simulations that multiply and divide such values many times may accumulate enough error that double precision is required. Source: IEEE 754-2019 standard (https://standards.ieee.org/ieee/754/6210/).

Why Does a Floating Point Converter Display a Slightly Different Value Than the Number You Entered?

Binary floating point uses base 2. Most decimal fractions are repeating in base 2, the same way 1/3 repeats in base 10. When you enter 0.1 into a 32-bit converter, the closest representable value is approximately 0.100000001490116, stored as 0x3DCCCCCD. The difference between what you typed and what was stored is the representation error, approximately 1.49 x 10^-8.

This is not a malfunction. Every floating point converter that correctly follows IEEE 754 will produce this result. The converter stores the nearest representable number, which is determined by the rounding mode in use.

What Are the Four IEEE 754 Rounding Modes and When Does Each One Apply?

IEEE 754 defines four rounding modes, each determining how the result is rounded when an exact value cannot be stored.

●        Round to nearest, ties to even (default): rounds to the nearest representable value. When the value falls exactly halfway between two candidates, the mode rounds to whichever has a 0 in its last mantissa bit. This prevents systematic upward or downward drift in long calculations and is what converters and processors use unless overridden.

●        Round toward positive Infinity: always rounds up to the next larger representable value. Used in interval arithmetic to compute an upper bound.

●        Round toward negative Infinity: always rounds down to the next smaller representable value. Used in interval arithmetic to compute a lower bound.

●        Round toward zero (truncate): drops extra bits regardless of their value. Fast but introduces a systematic rounding error in one direction.

In C, the rounding mode can be changed at runtime with fesetround() from the header <fenv.h>. Changing rounding modes at unexpected points in a codebase is a common source of hard-to-reproduce numerical bugs.

What Do NaN, Positive Infinity, Negative Infinity, and Subnormal Mean in Floating Point Conversion?

NaN has two variants. A quiet NaN propagates silently through arithmetic, turning every subsequent operation into NaN without raising an exception. A signalling NaN triggers a floating point exception on hardware that supports it. Most converters treat all NaN values as quiet NaN and use a single canonical bit pattern.

Subnormal numbers exist to implement gradual underflow. When the exponent field is all zeros, the hidden bit rule changes: the implied leading digit becomes 0 rather than 1. This allows the value to be represented with reduced precision, so the format can represent numbers much closer to zero than the minimum normalised value, at the cost of losing some significant digits.

If you type 'Infinity', '-Infinity', or 'NaN' into a converter, it will display the corresponding bit pattern. Zero produces either the positive or negative zero pattern depending on whether a sign is specified.

What Is bfloat16 and How Is It Different from the Standard 16-bit Half Precision Format?

bfloat16, also called Brain Float 16 or bf16, is a 16-bit floating point format developed by Google for use in tensor processing units and neural network training workloads. Despite having the same total bit count as float16, its internal structure is fundamentally different.

bfloat16 uses 8 exponent bits, the same as float32. This gives it the same dynamic range as single precision, which means converting a float32 value to bfloat16 never overflows. The conversion is a simple truncation of the last 16 mantissa bits. Converting float32 to float16, by contrast, can overflow for values above 65,504 and requires careful rescaling of the model.

The tradeoff is mantissa precision. bfloat16 stores only 7 mantissa bits compared to float16's 10, giving approximately 2 to 3 significant decimal digits. For neural network training, where gradient magnitudes vary over many orders of magnitude, maintaining the wide exponent range of bfloat16 is more valuable than the extra mantissa precision of float16. bfloat16 is supported natively on Google TPUs and NVIDIA Ampere and later GPU architectures.

How Do You Convert a Hexadecimal Bit Pattern Back to Its Decimal Floating Point Value?

When a memory debugger, binary file editor, or network packet inspector displays floating point data, the values appear as hexadecimal strings rather than decimal numbers. Converting these back to decimal requires reading the hex as a bit pattern and then applying the standard IEEE 754 decoding steps.

This example uses 0xC0B40000. Convert each hex digit to its 4-bit binary equivalent:

C       0   B   4       0   0   0       0

1100    0000 1011 0100    0000 0000 0000    0000

Reorganise the 32 bits into the three IEEE 754 fields:

Sign: 1  |  Exponent: 10000001  |  Mantissa: 01101000000000000000000

Decode:

●        Sign bit = 1, so the number is negative.

●        Exponent field = 10000001 = 129 in decimal. True exponent = 129 - 127 = 2.

●        Restore hidden bit: mantissa 01101 becomes significand 1.01101.

●        Apply exponent: 1.01101 x 2^2 = 101.101.

●        Convert to decimal: 4 + 1 + 0.5 + 0.125 = 5.625. With the sign: -5.625.

One distinction to keep clear: the hex string 0xC0B40000 is the bit pattern of the float read as an unsigned integer and printed in hex. It is not the same as a hexadecimal floating-point constant, which uses a format such as 0x1.6p1 (sign, significand in hex, and a decimal exponent after the letter p). These two hex forms encode the same number through completely different rules.

How Many Significant Decimal Digits Does a Floating Point Number Need to Round-Trip Without Loss?

Round-trip precision is the minimum number of significant decimal digits needed to convert a floating point number to a decimal string and then convert that string back to the exact same bit pattern. If fewer digits are used, some floating point values will recover as a different bit pattern after the round trip.

The distinction between these two figures matters in practice. Seven significant digits is how many decimal digits a single-precision float can distinguish from its neighbours. Nine digits is how many are needed to uniquely identify any given float so that it survives a decimal serialisation and deserialisation unchanged.

This is why C code that serialises floats for storage or transmission uses format specifiers such as %.9g for single precision and %.17g for double precision. Using fewer digits can cause silent data corruption in stored configurations, network protocols, and file formats.

How Is Floating Point Representation Applied Across Programming Languages, Hardware, and Scientific Computing?

IEEE 754 is the shared foundation beneath floating point in Python, C, C++, Java, JavaScript, and virtually every hardware floating point unit manufactured since the late 1980s. The standard ensures that the same binary encoding produces the same decimal result regardless of which platform reads it, which is the basis of portable numerical computing.

Implementations are not perfectly identical, however. The x87 FPU used in older x86 processors performed intermediate calculations using 80-bit extended precision registers, which meant that identical source code could produce slightly different results on different compilers or optimisation settings. Modern 64-bit code uses SSE2 instructions that compute in the exact format (32-bit or 64-bit) specified in the source, which eliminated most of these differences. Fused multiply-add (FMA) instructions, available on modern CPUs and GPUs, combine a multiplication and addition into a single rounded operation, which produces a more accurate result than performing the two operations separately with two separate rounding steps.

A concrete example of language-level behaviour: JavaScript's Number type is always a 64-bit IEEE 754 double. There is no 32-bit float in the language. This means 0.1 + 0.2 === 0.30000000000000004 evaluates to true in any JavaScript environment. The expression does not indicate a bug in the JavaScript engine; it is the correct result of adding the nearest double-precision representation of 0.1 to the nearest double-precision representation of 0.2.

How Do Python, C++, and JavaScript Handle Floating Point Numbers Differently Despite Using the Same IEEE 754 Standard?

All three languages implement IEEE 754, but each exposes the format in a different way and introduces different traps for the programmer.

Python: the built-in float type is always a 64-bit double. There is no 32-bit float built into the language, though libraries such as numpy use single precision explicitly. For applications where floating point rounding errors are not acceptable, such as accounting software, Python's decimal module provides arbitrary-precision decimal arithmetic. A common trap is comparing floats with ==:

0.1 + 0.2 == 0.3   # False -- use math.isclose() instead

C++: the language provides separate types for float (32-bit) and double (64-bit), and the programmer must choose. The most common trap is comparing floats with ==, which is nearly always incorrect for computed values because representation errors accumulate. A second trap is reading the bit pattern of a float by casting its address to an int* pointer, which is undefined behaviour in C++. The correct method is to use memcpy or a union, which the compiler handles correctly. In Java, the equivalent safe method is Float.floatToIntBits() and Float.intBitsToFloat().

For a broader comparison of how these and other languages behave with edge-case inputs, the floating point behavior across Python, C++, and JavaScript reference covers language-specific precision quirks and comparison pitfalls.

JavaScript: there is only one numeric type, Number, which is always a 64-bit double. Bitwise operators are an exception: they internally convert the number to a 32-bit signed integer, operate on it, and convert back to double. This means 2**53 and 2**53 + 1 are the same Number value, and arithmetic on integers above Number.MAX_SAFE_INTEGER (9,007,199,254,740,991) loses precision silently.

What Is a Binary to Decimal Converter and How Is It Different from a Floating Point Converter?

A binary to decimal converter takes a plain integer binary string, such as 1101, and returns its decimal equivalent using positional notation: 1x8 + 1x4 + 0x2 + 1x1 = 13. Each bit represents a power of 2, and the conversion is straightforward addition.

A floating point converter does something fundamentally different. It encodes a decimal number including its fractional part into the IEEE 754 three-field format. The bit string 0 10000001 101010000000000000000000000 does not decode to 6.625 using positional notation applied to all 32 bits as a single integer. It decodes to 6.625 only when the sign, exponent, and mantissa fields are read and interpreted according to the IEEE 754 rules.

The two converters solve different problems. Binary-to-decimal conversion is a step that appears inside the floating point conversion process (when converting the integer part of the decimal to binary in step 2, and when converting the binary result back to decimal in the reverse process). But the tools are not interchangeable. To convert integer values between binary and decimal without the IEEE 754 encoding, use a dedicated integer binary to decimal conversion calculator.

How Does Hexadecimal Representation Help Engineers Read and Verify IEEE 754 Floating Point Bit Patterns?

A 32-bit floating point bit string is 32 characters of 0s and 1s. The same value in hexadecimal is 8 characters: 0x40D40000. The compactness makes hex the standard format for displaying and communicating floating point bit patterns in debuggers, memory inspection tools, and technical documentation.

The conversion from binary to hex is mechanical: group the 32 bits into 8 groups of 4 bits, then convert each group to its hexadecimal digit. For 6.625:

0100  0000  1101  0100  0000  0000  0000  0000

  4 0 D     4 0 0     0 0   =  0x40D40000

One distinction that causes errors in practice: the hex string 0x40D40000 is the bit pattern of the float treated as an unsigned integer and printed in hex. It is not the same as a hexadecimal floating-point constant such as 0x1.a8p1, which is the C99 and Java notation for encoding the significand in hex with a decimal exponent. The two representations look similar but encode the same number through different rules.

Endianness determines byte order in memory. On a little-endian system (most modern x86 and ARM processors), the least significant byte is stored at the lowest memory address. A memory dump of 6.625 on a little-endian system shows the bytes in reverse order: 00 40 D4 40, which reads right-to-left as 0x40D44000. Engineers working with raw memory dumps or binary network protocols must account for byte order when interpreting floating point values. For general base conversion needs, a decimal to hexadecimal conversion tool handles the numeric conversion without the IEEE 754 encoding layer.

What Is Fixed-Point Arithmetic and When Is It Preferred Over Floating Point for Embedded and Financial Systems?

Fixed-point representation stores a number as an integer with an implied decimal point at a fixed position. A Q8.8 format, for example, uses 16 bits total: 8 bits for the integer part and 8 bits for the fractional part. The decimal point is always in the same position, which is why the format is called fixed-point.

Financial software frequently uses fixed-point rather than floating point for monetary values. Storing a price as an integer number of cents removes all floating point rounding errors from basic arithmetic. The value 1.99 stored as the integer 199 (cents) adds, subtracts, and compares exactly. Floating point representation of 1.99 in binary introduces a tiny error that can accumulate across thousands of transactions.

In embedded systems, many microcontrollers in the ARM Cortex-M0 class have no hardware FPU. Floating point operations on these processors are emulated in software, which can be 10 to 100 times slower than equivalent fixed-point operations and may violate real-time deadlines. Fixed-point arithmetic on the same hardware runs as fast as integer operations. For a detailed comparison of when each approach is appropriate, the fixed-point and floating-point arithmetic comparison provides a thorough side-by-side analysis.

How Do Floating Point Rounding Errors Accumulate in Iterative Calculations and How Can Developers Detect Them?

Each floating point operation introduces a rounding error that is usually smaller than one ULP (unit in the last place), the value of the last bit in the mantissa. For a single operation, this error is negligible. In iterative algorithms that perform millions of operations, such as numerical integration, matrix factorisation, or iterative solvers, these individual errors accumulate into results that differ visibly from the mathematically exact answer.

Catastrophic cancellation is a specific and severe form of error accumulation. It occurs when two nearly equal values are subtracted from each other. The subtraction cancels the leading significant bits, and the result consists mostly of the least significant bits, which carry the highest proportion of rounding error. A simple example: in single precision, (1.00000100 - 1.00000000) produces a result with only 2 or 3 accurate digits even though both input values had 7.

The Kahan summation algorithm is a standard technique for reducing accumulated rounding errors in floating point summation. It maintains a compensation variable that accumulates the low-order bits lost in each addition step and adds them back in the next iteration. For a sum of n terms, Kahan summation reduces the error from O(n) to O(1) regardless of n. Reference: Kahan, W., 1965, 'Further Remarks on Reducing Truncation Errors', Communications of the ACM, 8(1), p. 40.

Detection starts with comparing the stored value to the expected exact value. A floating point converter that displays representation error (such as the h-schmidt converter's 'error due to conversion' output) shows the gap between the stored value and the decimal you entered. For accumulated errors in a running calculation, the standard approach is to run the same calculation in double precision and compare the results. A discrepancy that grows as the iteration count increases points to error accumulation. ULP is the correct unit for quantifying these errors: an error of 1 ULP means the stored result differs from the exact result by no more than the value of the last mantissa bit. For the complete treatment of precision debugging techniques, the floating point precision and rounding error reference covers detection methods, algorithm-level fixes, and testing strategies.

Frequently Asked Questions

1. Why does 0.1 + 0.2 not equal 0.3?

Because 0.1 and 0.2 cannot be represented exactly in binary floating-point. Their stored values are slight approximations, so the result becomes 0.30000000000000004 instead of exactly 0.3.

2. What is the difference between float and double?

Float uses 32-bit precision with about 7 decimal digits, while double uses 64-bit precision with about 15–16 digits. Double offers greater accuracy but requires more memory.

3. What does NaN mean?

NaN (Not a Number) represents an undefined result, such as 0 ÷ 0 or √−1. Once a calculation produces NaN, it typically propagates through subsequent floating-point operations.

4. How can I check the exact stored value of 0.1?

Enter 0.1 into a floating-point converter to view its stored binary value. In 32-bit floats, it is approximately 0.10000000149, showing the small precision error introduced during conversion.

5. When should I use bfloat16 instead of float16?

Use bfloat16 when you need a wider numeric range, especially for AI training. Choose float16 when higher precision is more important and your hardware or application is optimized for it.