Re:E-Stop and Fuel, software that keeps you awake at night
by jacquesm on Sunday February 11, 2018 @02:24PM
(#16354250)
You make a valid point, pity to see it downvoted. Please keep in mind that in many dialects of BASIC you didn't have more datatypes than 'string' and 'float', and that the original program used floats. Even so, it is definitely possible to make reliable software using floating point, you just have to know exactly what you are doing and you will spend a lot of time on tests to ensure that you do not end up with nonsense output in edge cases.
Floating point is used regularly in avionics and other fields involving critical computations, it is not the floating point data type itself that is problematic, what is problematic is poorly understanding the underlying implementation details and what kind of limitations that will cause.
A good example is trying to count integers with more bits than the underlying precision of the implementation will allow. But in this particular case floating point would have been my 'tool of choice' anyway, fixed point would have introduced a lot of complications for very little gain - if any - gain and would not be worth it.
So in many cases I would agree with you that rounding errors could cause huge problems but in this particular case the inputs were in ranges where this could not happen, the software was tested exhaustively across all input ranges to ensure well defined behavior.
Floating point is used regularly in avionics and other fields involving critical computations, it is not the floating point data type itself that is problematic, what is problematic is poorly understanding the underlying implementation details and what kind of limitations that will cause.
A good example is trying to count integers with more bits than the underlying precision of the implementation will allow. But in this particular case floating point would have been my 'tool of choice' anyway, fixed point would have introduced a lot of complications for very little gain - if any - gain and would not be worth it.
So in many cases I would agree with you that rounding errors could cause huge problems but in this particular case the inputs were in ranges where this could not happen, the software was tested exhaustively across all input ranges to ensure well defined behavior.