# Why isn't it necessary to store an integer part of significant in IEEE754 floating point notation?

We see that there is a sign, exponent, and mantissa part for the notation. But, there is no location for the significant bit.

Why isn't it necessary to store an integer part of significant in IEEE754 floating point notation?

• Have you seen: en.wikipedia.org/wiki/Significand ? It is stored, just not explicitly. – Evil Mar 18 at 22:17
• What would that integer part be? – gnasher729 Mar 18 at 22:18
• @gnasher729, 1. – user366312 Mar 18 at 22:25
• So if you know the integer part is 1, why would you want to waste space to store it? – gnasher729 Mar 18 at 22:51

There are two tricks used here.

The first trick is to realise that any number can be expressed with a single whole digit and a fractional part by modifying the exponent.

eg:

  = 435.32 * 10^3
= 43.532 * 10^4
= 4.3532 * 10^5

= 0.00453 * 10^1
=  0.0453 * 10^0
=   0.453 * 10^-1
=    4.53 * 10^-2


The second trick is to notice that this single whole digit is never zero. So when the number is expressed in binary (0, 1) that digit must always be 1.

Therefore if we mandate that the number is stored in binary, and the exponent is always adjusted to express the number as a single whole digit and a fractional part, the whole digit can be optimised away as it never varies. This leaves just the sign, exponent, and fractional parts of the number to encode.

That being said (as pointed out in the comments), the IEEE754 standard does include "denormalised" numbers which as you might guess do not have a leading implied 1, but are instead lead by an implied 0.

These numbers have the smallest possible exponent making these values truly tiny. The point of presuming a zero here is to allow the storage of even smaller values than could have otherwise been expressed.

Essentially it is a compromise, by altering the rule for the smallest possible exponent a series of even smaller numbers with reducing precision can be stored. The cost for this is that numbers at the 2^smallest-exponent cannot be accurately stored.

• It's never $0$, except when it is. – Derek Elkins Mar 19 at 6:17
• @DerekElkins Fair point, the format does indeed include provision for denormalisation. I thought it was clear that the query was about why the implied 1 wasn't encoded, but I have updated my answer. – Kain0_0 Mar 19 at 8:07