Representation of Real Numbers in Binary

So, we've dabbled in whole numbers in binary, and even those slightly awkward fractions with fixed point. But what about those really fiddly numbers – the ones with lots of decimal places, or the ridiculously huge or tiny ones? Well, that's where things get a bit more involved, and we venture into the realm of representing real numbers in binary.

As we know, in binary, each column to the left of the (implied or explicit) binary point represents increasing powers of 2 (1, 2, 4, 8, and so on). But if we want to represent fractions, we extend this to the right of the binary point. The first column after the point is 2^-1 (or 0.5), the next is 2^-2 (or 0.25), then 2^-3 (or 0.125), and so on. It's like the powers of 2 going on a digital diet, getting smaller and smaller.

Floating Point Binary: For the Really Big (and Really Small) Fish!

However, fixed point binary can run into trouble when you're dealing with numbers that are either incredibly large or incredibly tiny. Imagine trying to write the distance to the Sun or the size of an atom using a fixed number of bits with the point in the same place – you'd run out of room pretty quickly!

That's where floating point binary comes to the rescue. It's a much more flexible system, a bit like the scientific notation you might have used in science lessons (e.g., 1.23 × 10⁵). In floating point binary, a number is typically represented in the form a.aa × 2^b, where 'a.aa' is the mantissa (the significant digits) and 'b' is the exponent (telling you how many places to shift the binary point).

To work out the decimal value, you essentially take the binary point in the mantissa and move it to the right (if the exponent is positive) or to the left (if the exponent is negative) by the number of places given in the exponent. Then you just convert the resulting binary number to decimal.

Normalisation: Making Binary Numbers Look Their Best (and Most Precise)!

Ah, normalisation. In the slightly peculiar world of storing binary numbers, especially those floating about with their decimal points, there's often a need to make sure they're presented in a standard, most precise way. Think of it as giving your binary numbers a bit of a digital makeover.

For a positive binary number, normalisation basically means chopping off any unnecessary leading zeros. You know, those zeros at the very beginning that don't actually change the value of the number (like writing 007 instead of 7 – looks a bit silly). By getting rid of them, you make the most of the available bits to store the actual significant digits.

Now, for a negative binary number (often in two's complement form), the rule is similar, but you chop off any leading ones. Again, these leading ones don't add to the precision and can be discarded to make the representation more efficient.

This tidying-up process is particularly important for floating point numbers. A normalised floating point number has a very specific look: it must always start with either 0.1 or 1.0. This ensures that the most significant bit is right after the binary point (for positive numbers) or the first two bits are '10' after normalisation of a negative mantissa. It's all about having that first significant digit right next to the point to maximise the precision you can store.

Normalising a Floating Point Number: The Digital Point Shift!

So, how do you actually normalise a floating point binary number? Well, you simply move the binary point within the mantissa (that's the main part of the number) either to the left or to the right until it satisfies that golden rule of starting with 0.1 or 1.0.

But, and this is a crucial but, you can't just go moving the point willy-nilly without keeping track of things! Every time you move the binary point, you have to adjust the exponent (that's the power of 2 that tells you where the point really should be).

If you move the binary point to the right by a certain number of places to get it into the normalised form, you have to decrease the exponent by the same number. It's like saying, "I've made the mantissa smaller, so I need to make the power of 2 bigger to compensate."

Conversely, if you move the binary point to the left, you have to increase the exponent by the same amount. "I've made the mantissa bigger, so I need a smaller power of 2."

It's a bit of a digital dance, moving the point and adjusting the exponent to keep the overall value of the number the same while ensuring it's in that nice, neat normalised form. All for the sake of squeezing the most accuracy out of those precious few bits!

Range and Precision: The Digital Give and Take!

So, we've seen that floating point binary is a clever way to represent a vast range of numbers. But because of that constant juggling act between range and precision, the digital version of a real number isn't always a perfect copy of the real thing. Sometimes, we have to make do with a close approximation, and that's where errors sneak in like digital gremlins.

In the world of floating point binary, if you decide to use more bits for the exponent, you can represent a much wider range of numbers – both incredibly large and incredibly small. The binary point can effectively 'float' over a much greater distance. However, using more bits for the exponent leaves fewer bits available for the mantissa, which means you have fewer significant digits to represent the actual value of the number, thus reducing the precision. You might be able to store a number as big as the national debt, but not necessarily down to the last digital penny.

On the flip side, if you allocate more bits to the mantissa, you can represent numbers with much greater precision – you can store more significant figures and have a more accurate representation. However, this comes at the cost of having fewer bits for the exponent, which limits the overall range of numbers you can represent. You might be able to store the width of a human hair with incredible accuracy, but you might struggle to represent the distance to the nearest star.

So, it's a constant balancing act, this range versus precision malarkey. The designers of computer systems have to decide how to allocate those precious bits based on the types of calculations the computer will be doing. It's a bit like deciding whether you need a really long measuring tape that isn't very finely marked, or a shorter one with very precise markings. You can't usually have both to the maximum!

Errors: When Digital Reality Doesn't Quite Match Up!

So, we've seen that floating point binary is a clever way to represent a vast range of numbers. But because of that constant juggling act between range and precision, the digital version of a real number isn't always a perfect copy of the real thing. Sometimes, we have to make do with a close approximation, and that's where errors sneak in like digital gremlins.

Take their example: the number 76.65625. To store this with a decent amount of accuracy, you might need a certain number of bits for the mantissa (they suggest 13 bits) and some for the exponent (4 bits in their example). But what if the computer only gives you a smaller number of bits for the mantissa, say only 10? Well, you'd have to chop off some of the less significant bits, and suddenly, your stored value might be 76.625. It's close, but it's not quite the same as the original. That little difference? That's an error.

These errors are an inherent part of using floating point binary to represent real numbers. Because we're using a finite number of bits to try and capture the infinite possibilities of real numbers (including those with never-ending decimal expansions!), we often have to make approximations. It's a bit like trying to measure a wiggly coastline with a straight ruler – you're bound to have some inaccuracies. Understanding these potential errors is crucial for anyone doing serious number-crunching with computers, especially in scientific and engineering fields. You need to know how much you can trust your digital results!