[xyzzy_plugh]

The binary form is important to understand the implementation details. You even mention underflow. It's difficult for most people to initially understand why you can't store a large number that can be represented by an equivalent size integer as a float accurately.

The binary form handily demonstrates the limitations. Understanding the floating point instructions is kinda optional but still valuable.

Otherwise everyone should just use varint-encoded arbitrary precision numbers.

[colejohnson66]

It also explains why 0.1+0.2 is not 0.3. With binary IEEE-754 floats, none of those can be represented exactly[a]. With decimal IEEE-754 floats, it's possible, but the majority of hardware people interact with works on binary floats.

[a]: Sure, if you `console.log(0.1)`, you'll get 0.1, but it's not possible to express it in binary exactly; only after rounding. 0.5, however, is exactly representable.

[jacobolus]

    Python 3.9.5
    >>> 0.1.hex()
    '0x1.999999999999ap-4'
    >>> 0.2.hex()
    '0x1.999999999999ap-3'
    >>> (0.1 + 0.2).hex()
    '0x1.3333333333334p-2'
    >>> 0.3.hex()
    '0x1.3333333333333p-2'

[colejohnson66]

But they are repeating. So, by definition, they are not exactly representable in a (binary) floating point system. Again, that’s why 0.1 + 0.2 is not 0.3 in binary floating point.

[jacobolus]

These are not "repeating". This is showing the exact binary representation of the nearest double precision value in each case.

[jhgb]

> It's difficult for most people to initially understand why you can't store a large number that can be represented by an equivalent size integer as a float accurately.

Because you don't have all the digits available just for the mantissa? That seems quite intuitive to me, even if you don't know about the corner cases of FP. This isn't one of them.

[bee_rider]

I was going to respond with something like this. I think for getting a general flavor*, just talking about scientific notation with rounding to a particular number of digits at every step is fine.

I guess -- the one thing that explicitly looking at the bits does bring to the table, is the understanding that (of course) the number of bits or digits in the mantissa must be less than the number of bits or digits in an equivalent length integer. Of course, this is pretty obvious if you think about the fact that they are the same size in memory, but if we're talking about sizes in memory, then I guess we're talking about bits implicitly, so may as well make it explicit.

* actually, much more than just getting a general flavor, most of the time in numerical linear algebra stuff the actual bitwise representation is usually irrelevant, so you can get pretty far without thinking about bits.