[hugatest]

And why is that necessary knowledge?

Don't get me wrong, once you go down to embedded you sometimes do need to know and sometimes it just improves your understanding (and it's kinda cool anyway), but if you do high-level work, perhaps web work, all you need to know is the abstract interface of floats as a data type. What operations you can do, what is guaranteed about the result of those operations (loss of precision etc). In other words, why would a Haskell programmer need to know the IEEE FP standard?

[dolmen]

You have to understand that float are negative powers of 2 and that conversion from decimal is not as straightforward as for integer: conversion from decimal often leads to loss of precision contrary to what happens for integers.

[thfuran]

You don't need to know anything about how they're represented to know they can't represent all decimal values.

[visarga]

Maybe not everyone needs to know, but for example it's important to know about it in ML. You can have overflow, underflow, non-deterministic addition when parallelised, or just need to speed up your network.

[hugatest]

Right. You can know these abstract properties though without knowing how a float is actually represented in memory.

[randcraw]

Debugging. If you don't know how your code is translated into CPU ops, you won't be able to recognize the clues that malfunctions almost always provide when code misbehaves. Translators, compilers, libraries, and new code routinely have bugs. Depending on a google search to pin down the source of your troubles often fails, and of course is of no help at all diagnosing your own bugs.

It also depends on your philosophy. I want to master my machine not be its servant.

[dfox]

Because not caring how FP values are stored and what the implications are (or even not realising that you favorite programming language uses FP by default) is a particularly fast way to become the "minus 10 times programmer".

Storing monetary values as FP is one thing, but I've seen phone numbers and other numeric identifiers (long time ago before PCI-DSS even credit card numbers) stored as FP values, with predictable results.

[hugatest]

As long as you know the implications, you don't need to know how the values are stored.

You may say it's easier to know how they are stored, then you can derive the implications anytime you need them. Maybe that works for you, but most people who I know that got this wrong do actually know how FP values are stored, they are just drawing the wrong conclusions. So better focus on the implications, cause it's those that matter.

I already expressed this in the GP comment, and it's a little shocking to see all the replies that didn't actually pick up on that.

[digging]

> Because not caring how FP values are stored and what the implications are (or even not realising that you favorite programming language uses FP by default) is a particularly fast way to become the "minus 10 times programmer".

I don't think that's true at all. You're merely looking at a symptom of someone who is intrinsically a negative performer. But that's rather like assuming that someone with a cough has tuberculosis.

[fnord77]

because you would know not to represent money as a float in any sort of serious system

or any other value where you have repeated calculations that would introduce errors