It's all about *precision.* Sure, you might not need 14 digits to store a high score in your game (unless you're Konami or some other big TCG maker that doesn't care about point inflation), but keep in mind what you're programming on. It's a calculator, and calculators are supposed to be accurate. Imagine if calculators could handle only integer numbers from 0 to 65,535! How fun would that be?

But that presents a problem: The Z80 calculator can only handle two-byte registers, or integers up to 65535. How would you use that for fractions and decimals? Sure, you could use **8.8 fixed-point notation**, where the first byte is the integer part and the second is the fraction. But that still gives you only 16 bits of precision, limiting you to numbers between 0 and 255 (or −128 to 127 signed), with fractions in multiples of 1/256. The closest you could get to π would be 3.140625. So you turn to **multi-byte fixed point**, where you store fixed-point numbers as long as you want in RAM. But that means you're limited in digits to how much memory you plan to use. For a number like 10^{99}, you'd need at least 42 bytes!

That's where floating point comes in. **Floating-point numbers** are stored in RAM, like fixed point, but in scientific notation. In other words, the number could start at any decimal place you want, and extend as many digits you want. There's no need to extend the number to the decimal point, and you can keep each number the same size. This is clearly an advantage on a calculator that handles numbers up to 9.9999999999999×10^{99} with a bit more than 24 KB of RAM to work with, and that's what this tutorial teaches you.