For transactional financial calculations decimal fixed point representation is generally preferred because of things like rounding errors which accumulate in such things as running totals, and balances. Sometimes these can involve tens or hundreds of thousands of accumulations. That's one of the reasons that many older computers had decimal number representations, usually packed decimal, along with the instructions to support it. Typically those could support up to 31 decimal digits of precision. Also, IEEE754 does allow for base 10 as well as base 2 exponents. I'd also add that cumulative FP rounding errors can quickly become apparent, even in something like an Excel spreadsheet and you have to be very careful to avoid those sort of problems.

Great video, Gary. Glad you pointed out the classic 7 sig-fig rounding problem. One other snag, for programmers, is: If (floata == floatb) // dangerous comparison 👍

While floating point numbers are stored as binary fractions between 1 and 2 with an exponent, it's actually equivalent to an integer multiplied by a power of 2. For example 1.5 is equal to 3×2^-1, and 1.25 is equal to 5×2^-2 and so on. So for example if we have a binary fraction with 8 bits after the 'decimal point', together with an exponent, we can shift the mantissa to the left by 8 places and subtract 8 from the exponent to get the same number. (I find this picture especially useful in digital audio when considering the difference between 24bit integer and 32bit float PCM.) The advantage of the binary fraction approach is one extra bit of mantissa precision for the same total number of bits. The clever observation is that for binary numbers that are not identically zero, the leading digit is _always_ 1. Thus if the number is nonzero, you don't have to actually use a bit to store the leading digit. (So they use the entirely-zero bit pattern as a special case to store zero.)

This is great. Thank you!

Another great explainer. I recently read there is a new format specifically for numbers between -1 and +1 - used in AI / ML. Would you be able to get into that? It's supposed to be an order of magnitude faster than IEEE-754

1:42 picture is not correct, it should be 32768, not 32786

There is FP64 too, for big scary numbers (AKA Float64, or Double-Precision)

11:53

I've only ever used floating point numbers as a last resort (for the reasons you have pointed out). If, for example, you want your microcontroller to monitor room air temperature, then you can easily represent -50°C to +50°C in a 2 byte integer with 2 decimal precision. As a bonus, your program will be smaller and faster (as if anyone cares about that these days :D ) and will exhibit a lesser "astonishment factor".

Would you cover Posit floating point format?

10:08 Don't use floating point for currency! It's not going to be OK. Used fixed points instead. Floating point is developed so that it can efficiently store both very big and very small numbers. The precision goes down when you store bigger numbers. The errors can easily crop up even with smaller numbers when you do arithmetic operations with them. This is not acceptable for monetary computations.

There's FP4 too ;)

I want to hear you say “if you want to understand 3body problem, please let me explain “

Whereby 42 is an integer, namely that what you get if you multiply 6 by 9.

Only the most astute fans know the true meaning behind the number 42. yes it has one. no, you can't look it up. the answer is hilarious, and profound, and superbly sublimely simple, its amazing that it wasnt figured out decades ago. no i cant tell you, yes i can be persuaded to give a hint if you'd like to figure it for yourself

Your 15 column is on error. It should be 32768, not 32786. Floats are used WAY TOO MUCH. Currency is NOT represented as floats & rounded. That's why there continues to be packed BCD representation in computers.

2^15 is 32768 not 32786 :)

what if the reason we can't unify quantum mechanics and relativity is because the further away something gets from the observer, the less the precision of quantization?

I propose dropping all this complication and we store everything in bcd, thats 2 digits per byte and storage is cheap now. you can even assign a byte to state length of bcd string and a 2nd byte to give length of anything fractional so thats 255 bytes or 510 digits then '.' 510 digits ...... would make for interesting routines for math...