I think you're missing the point. floating point isn't madness, but people thinking it represents the real numbers without stopping to consider how it works is madness.
For example, just consider the number of bugs that come down to integer over/under flow. The reality is that we like to work with a simplistic model of what is going on, and ignoring the hard to reason about edge cases really does simplify problems, and if on revisiting the code we can either handle or rule out these cases as ever happening, then we're golden.
As for fixed point arithmetic, this is how DSPs worked for years, and there are still lots of edge cases to worry about. A typical application would see many multiply accumulates for something like an FIR filter, so you still have to consider how large the value can end up, and split your integer into a suitable scaling factor to avoid overflow whilst trading off precision. The whole point of floating point is that this tradeoff is always carried out on your behalf.
Thanks for your reply, this is an interesting perspective - based on your comment, it seems likely that you have more real-world experience with these issues than I do.
Regarding floating point performing this tradeoff for you: yes, I understand that floating point arithmetic trades simplicity for greater dynamic range, giving lots of precision to small values and less precision to large values. You can tackle some of these issues with fixed point arithmetic at the cost of increased memory usage. For example, instead of using a 32 bit float, you could use a 64 bit fixed point value, where the most significant 32 bits represent the integral part and the least significant 32 bits represent the fractional part. Obviously this type offers both much greater range and greater precision (at every scale) than the 32 bit float, at the cost of 2x memory usage. I suspect that the 64 bit fixed point type might still be faster to work with in hardware, due to the relative simplicity of implementing fixed point arithmetic in hardware. What do you think?
Why would you compare a 64 bit fix pint with a 32 bit float? If you can afford twice the space you would use a 64 bit float. Also I'm not an hardware designer but I think that a 32 bit float multiplier is going to be less complex than a 64 bit fix point multiplier.
> floating point isn't madness, but people thinking it represents the real numbers without stopping to consider how it works is madness
This is certainly true in some places, but I would wager that a large number of JS devs are completely ignorant of floating point, and many of them likely lack the background knowledge to understand it.
No need to pick on JS. Most devs in any mainstream language are ignorant of how IEEE754 floating point works. In the 2000s, it was Java developers. In the 90s, Perl programmers. Today it's JS and Python. In another 10 years, it could be Rust. https://0.30000000000000004.com/
For example, just consider the number of bugs that come down to integer over/under flow. The reality is that we like to work with a simplistic model of what is going on, and ignoring the hard to reason about edge cases really does simplify problems, and if on revisiting the code we can either handle or rule out these cases as ever happening, then we're golden.
As for fixed point arithmetic, this is how DSPs worked for years, and there are still lots of edge cases to worry about. A typical application would see many multiply accumulates for something like an FIR filter, so you still have to consider how large the value can end up, and split your integer into a suitable scaling factor to avoid overflow whilst trading off precision. The whole point of floating point is that this tradeoff is always carried out on your behalf.
But don't get me started on denormals...