You really have two questions here.

Why does anyone need floating point math, anyway?

As Karl Bielefeldt points out, floating point numbers let you model continuous quantities - and you find those all over the place - not just in the physical world, but even places like business and finance.

I've used floating point math in many, many areas in my programming career: chemistry, working on AutoCAD, and even writing a Monte Carlo simulator to do financial predictions. In fact, there's a guy named David E. Shaw who's used applied floating-point based scientific modeling techniques to Wall Street to make billions.

And, of course, there's computer graphics. I consult on developing eye candy for user interfaces, and trying to do that nowadays without a solid understanding of floating point, trigonometry, calculus, and linear algebra, would be like showing up to a gun fight with a pocketknife.

Why would anyone need a float versus a double?

With IEEE 754 standard representations, a 32-bit float gives you about 7 decimal digits of accuracy, and exponents in the range 10^-38 to 10^38. A 64-bit double gives you about 15 decimal digits of accuracy, and exponents in the range 10^-307 to 10^307.

It might seem like a float would be enough for what anybody would reasonably need, but it's not. For instance, many real-world quantities are measured in more than 7 decimal digits.

But more subtly, there's a problem colloquially called "roundoff error". Binary floating point representations are only valid for values whose fractional parts have a denominator that's a power of 2, like 1/2, 1/4, 3/4, etc. To represent other fractions, like 1/10, you "round" the value to the closest binary fraction, but it's a little wrong - that's the "roundoff error". Then when you do math on those inaccurate numbers, the inaccuracies in the results can be far worse than what you started with - sometimes the error percentages multiply, or even pile up exponentially.

Anyway, the more binary digits you have to work with, the closer your rounded-off binary representation will be to the number you're trying to represent, so its roundoff error will be smaller. Then when you do math on it, if you have a lot of digits to work with, you can do a lot more operations before the cumulative roundoff error piles up to where it's a problem.

Actually, 64-bit doubles with their 15 decimal digits aren't good enough for many applications. I was using 80-bit floating point numbers in 1985, and IEEE now defines a 128-bit (16-byte) floating point type, for which I can imagine uses.

You really have two questions here.

Why does anyone need floating point math, anyway?

As Karl Bielefeldt points out, floating point numbers let you model continuous quantities - and you find those all over the place - not just in the physical world, but even places like business and finance.

I've used floating point math in many, many areas in my programming career: chemistry, working on AutoCAD, and even writing a Monte Carlo simulator to do financial predictions. In fact, there's a guy named David E. Shaw who's used applied floating-point based scientific modeling techniques to Wall Street to make billions.

And, of course, there's computer graphics. I consult on developing eye candy for user interfaces, and trying to do that nowadays without a solid understanding of floating point, trigonometry, calculus, and linear algebra, would be like showing up to a gun fight with a pocketknife.

Why would anyone need a float versus a double?

With IEEE 754 standard representations, a 32-bit float gives you about 7 decimal digits of accuracy, and exponents in the range 10^-38 to 10³⁸. A 64-bit double gives you about 15 decimal digits of accuracy, and exponents in the range 10^-307 to 10³⁰⁷.

It might seem like a float would be enough for what anybody would reasonably need, but it's not. For instance, many real-world quantities are measured in more than 7 decimal digits.

But more subtly, there's a problem colloquially called "roundoff error". Binary floating point representations are only valid for values whose fractional parts have a denominator that's a power of 2, like 1/2, 1/4, 3/4, etc. To represent other fractions, like 1/10, you "round" the value to the closest binary fraction, but it's a little wrong - that's the "roundoff error". Then when you do math on those inaccurate numbers, the inaccuracies in the results can be far worse than what you started with - sometimes the error percentages multiply, or even pile up exponentially.

Anyway, the more binary digits you have to work with, the closer your rounded-off binary representation will be to the number you're trying to represent, so its roundoff error will be smaller. Then when you do math on it, if you have a lot of digits to work with, you can do a lot more operations before the cumulative roundoff error piles up to where it's a problem.

Actually, 64-bit doubles with their 15 decimal digits aren't good enough for many applications. I was using 80-bit floating point numbers in 1985, and IEEE now defines a 128-bit (16-byte) floating point type, for which I can imagine uses.

You really have two questions here.

Why does anyone need floating point math, anyway?

As Karl Bielefeldt points out, floating point numbers let you model continuous quantities - and you find those all over the place - not just in the physical world, but even places like business and finance.

I've used floating point math in many, many areas in my programming career: chemistry, working on AutoCAD, and even writing a Monte Carlo simulator to do financial predictions. In fact, there's a guy named David E. Shaw who's used applied floating-point based scientific modeling techniques to Wall Street to make billions.

And, of course, there's computer graphics. I consult on developing eye candy for user interfaces, and trying to do that nowadays without a solid understanding of floating point, trigonometry, calculus, and linear algebra, would be like showing up to a gun fight with a pocketknife.

Why would anyone need a float versus a double?

With IEEE 754 standard representations, a 32-bit float gives you about 7 decimal digits of accuracy, and exponents in the range 10^-38 to 10^38. A 64-bit double gives you about 15 decimal digits of accuracy, and exponents in the range 10^-307 to 10^307.

It might seem like a float would be enough for what anybody would reasonably need, but it's not. For instance, many real-world quantities are measured in more than 7 decimal digits.

But more subtly, there's a problem colloquially called "roundoff error". Binary floating point representations are only valid for values whose fractional parts have a denominator that's a power of 2, like 1/2, 1/4, 3/4, etc. To represent other fractions, like 1/10, you "round" the value to the closest binary fraction, but it's a little wrong - that's the "roundoff error". Then when you do math on those inaccurate numbers, the inaccuracies in the results can be far worse than what you started with - sometimes the error percentages multiply, or even pile up exponentially.

Anyway, the more binary digits you have to work with, the closer your rounded-off binary representation will be to the number you're trying to represent, so its roundoff error will be smaller. Then when you do math on it, if you have a lot of digits to work with, you can do a lot more operations before the cumulative roundoff error piles up to where it's a problem.

Actually, 64-bit doubles with their 15 decimal digits aren't good enough for many applications. I was using 80-bit floating point numbers in 1985, and IEEE now defines a 128-bit (64 byte) floating point type, for which I can imagine uses.

You really have two questions here.

Why does anyone need floating point math, anyway?

As Karl Bielefeldt points out, floating point numbers let you model continuous quantities - and you find those all over the place - not just in the physical world, but even places like business and finance.

I've used floating point math in many, many areas in my programming career: chemistry, working on AutoCAD, and even writing a Monte Carlo simulator to do financial predictions. In fact, there's a guy named David E. Shaw who's used applied floating-point based scientific modeling techniques to Wall Street to make billions.

And, of course, there's computer graphics. I consult on developing eye candy for user interfaces, and trying to do that nowadays without a solid understanding of floating point, trigonometry, calculus, and linear algebra, would be like showing up to a gun fight with a pocketknife.

Why would anyone need a float versus a double?

With IEEE 754 standard representations, a 32-bit float gives you about 7 decimal digits of accuracy, and exponents in the range 10^-38 to 10^38. A 64-bit double gives you about 15 decimal digits of accuracy, and exponents in the range 10^-307 to 10^307.

It might seem like a float would be enough for what anybody would reasonably need, but it's not. For instance, many real-world quantities are measured in more than 7 decimal digits.

But more subtly, there's a problem colloquially called "roundoff error". Binary floating point representations are only valid for values whose fractional parts have a denominator that's a power of 2, like 1/2, 1/4, 3/4, etc. To represent other fractions, like 1/10, you "round" the value to the closest binary fraction, but it's a little wrong - that's the "roundoff error". Then when you do math on those inaccurate numbers, the inaccuracies in the results can be far worse than what you started with - sometimes the error percentages multiply, or even pile up exponentially.

Anyway, the more binary digits you have to work with, the closer your rounded-off binary representation will be to the number you're trying to represent, so its roundoff error will be smaller. Then when you do math on it, if you have a lot of digits to work with, you can do a lot more operations before the cumulative roundoff error piles up to where it's a problem.

Actually, 64-bit doubles with their 15 decimal digits aren't good enough for many applications. I was using 80-bit floating point numbers in 1985, and IEEE now defines a 128-bit (16-byte) floating point type, for which I can imagine uses.