4 ms·

Note that there are at least three ways to get the wrong answer with the correct code : - Modeling and discretization errors (usually unavoidable but well unde

Note that there are at least three ways to get the wrong answer with the correct code : - Modeling and discretization errors (usually unavoidable but well understood). - Uncertainties from the inputs (we have tools to get a feeling for their impact on the result). - Floating point arithmetic (scientist tend to be unaware of its impact and/or consider that it is negligible next to the other sources of error) My PhD covers methods to quantify the impact of floating-point arithmetic and suffice to say that you probably grossly overestimate the number of significant digits of your simulation. On the subject I recommend "What Every Computer Scientist Should Know About Floating-Point Arithmetic" : https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf

btrettel 8y ago
"Model inadequacy", i.e., the model being wrong, is also a major source of error. In my training, it was basically assumed that floating point errors are negligible these days, so I'll check out your recommendation. If you've published any of your own more recent work, I'd be happy to see that as well.
- nestorD 8y ago
  I have a paper that should be out in few months (I might do a show Hackernews). It details a method+tool, which provides fine-grained information out of the box, that I used on published simulation codes. In the meantime, if you want a way to explore this subject on your own applications, I would recommend Verrou[0]. It has its shortcomings but it is probably the current easiest way to evaluate the impact of floating-point arithmetic on your code (I did not work on it but exchanged a lot with their team). [0] https://github.com/edf-hpc/verrou https://github.com/edf-hpc/verrou
- mehrdadn 8y ago
  > In my training, it was basically assumed that floating point errors were negligible these days Yeah, that's what most of us think initially. The problem is that the effects of error can compound in many ways -- nonlinearities, feedback, etc. can all wreck your accuracy enough to make the results meaningless. A really instructive counterexample for me was solving quadratics. Easy, right? Just try writing a solver for ax^2 + bx + c = 0. Now try breaking it. If all you did was use the quadratic formula, you should find that it's quite easy to break it, and surprisingly difficult to write a robust solver. (If you're completely stuck, consider the most obvious edge case: what if a ≈ 0? Any other scenarios you can think of?)

btrettel 8y ago

"Model inadequacy", i.e., the model being wrong, is also a major source of error. In my training, it was basically assumed that floating point errors are negligible these days, so I'll check out your recommendation. If you've published any of your own more recent work, I'd be happy to see that as well.

nestorD 8y ago
I have a paper that should be out in few months (I might do a show Hackernews). It details a method+tool, which provides fine-grained information out of the box, that I used on published simulation codes. In the meantime, if you want a way to explore this subject on your own applications, I would recommend Verrou[0]. It has its shortcomings but it is probably the current easiest way to evaluate the impact of floating-point arithmetic on your code (I did not work on it but exchanged a lot with their team). [0] https://github.com/edf-hpc/verrou https://github.com/edf-hpc/verrou
mehrdadn 8y ago
> In my training, it was basically assumed that floating point errors were negligible these days Yeah, that's what most of us think initially. The problem is that the effects of error can compound in many ways -- nonlinearities, feedback, etc. can all wreck your accuracy enough to make the results meaningless. A really instructive counterexample for me was solving quadratics. Easy, right? Just try writing a solver for ax^2 + bx + c = 0. Now try breaking it. If all you did was use the quadratic formula, you should find that it's quite easy to break it, and surprisingly difficult to write a robust solver. (If you're completely stuck, consider the most obvious edge case: what if a ≈ 0? Any other scenarios you can think of?)