And I take exception to your lack of worry about floating point errors (FPE). Trefethen's statement was made only in response to the outrageous mischaracteriza

And I take exception to your lack of worry about floating point errors (FPE). Trefethen's statement was made only in response to the outrageous mischaracterization of numerical-analysis by non-numerical analysts as "people who are mainly concerned about errors in their calculations". Trefethen wrote a paper debunking the claim that numerical analysis is all or mostly about error analysis. Now back to FPE. Let me give you a few arguments for why FPE is a major headache: - Consider a random collinear triplet of points on a 2D plane. What I mean by that is three (x, y) pairs (x1, y1), (x2, y2), (x3, y3) such that they make a straight line. Do you know that if you generate such triplets with random angles, 99.999% of your triplets would not be collinear if you're using FP? Why? because FP representation is not exact except for a hopefully small number of scenarios. E.g., if your lines are perfectly vertical (x1 == x2 == x3) or perfectly horizontal (y1 == y2 == y3), or a perfect diagonal (x1 == y1, x2 == y2, x3 == y) you'd have collinearity, otherwise it's a toss up. For any other lines, you could try to be very careful in picking x and y values, but then you probably compromised some other property of your points depending on the application (and btw, when you decide to carefully pick x and y values, welcome to the world of 'being concerned about FP' already). This is the well known problem of 'robustness' in computer graphics, and something CG researchers have to spend a lot of time on, "beyond" their work of actually having created a correct algorithm, and "beyond" actually having implemented a performant version of it. - You compare floating-point error magnitudes with modeling error magnitudes. I'm afraid that's a silly comparison. When you're working as a numerical analyst, the modeling domain is the primary part of your research activity. You're expected to spend time on looking at modeling and associated errors. FPE could have much smaller magnitudes, but when you have them, they're a serious headache and a distraction, and force you to drop down to system-programming and dealing with the IEEE standard and how you can circumvent the negative affects. That's like saying "I'm not concerned about leaks in the fluid systems of my car because they're insignificant compared to my worries in driving the car in dangerous conditions like snowy weather, steep hills, rough terrain". - Also by the way, good luck creating a reproducible system primarily based on FP if it has to run on different architectures. Various microprocessors like Intel x86, x86_64, arm, power, etc, etc have implemented their own slightly differing ways of doing single and double precision operations like addition, multiplication, trig functions, etc. Your FP numbers are pretty much guaranteed to differ in their 10 or 11th decimal points. You might think this is not a big deal. But then make sure your system is not running for hours or days, (and definitely make sure your system is not for critical applications like medical or space, etc), or you will encounter these errors accumulating and results diverging away from each other in more and more significant decimal places. So to summarize, if you're not worried about FPE, I'm afraid it's gives a strong impression that you're only getting started in FP based work (hands-on numerical analysis, computational science, stats/ML, etc) and have not acquired enough experience to realize its importance. edit: I see you have a PhD in applied math based on non-linear PDEs, and a postdoc. So my question to you is, did your PhD involve implementing and running numerical algorithms (meaning writing/compiling/testing actual numerical code)? If the answer is yes then I'm extremely surprised that you don't worry about FPE.