Search code examples
exceptionfloating-pointoverflowieee-754

Are there known safety issues caused by floating-point overflow?


IEEE754 standard seems to give floating-point overflow a pass by introducing the infinity representation. It seems to me that overflow is more tolerated in floats than in integers. My question is, how dangerous is floating-point overflow? Are there known safety issues caused by undetected floating-point overflow?

(The well-known Ariane 5 explosion is caused by double -> long int conversion, which is not a proper floating-point overflow discussed here.)


Solution

  • In a context of high safety level needed, you shall check for all errors that can affect the result in a substantial way. That sounds tautologic but is still the main principle and nobody can tell you more from his side view, without digging into details. But some general recipes are still expressable. Particularly, if you get INF as a result, this likely means you have no result at all, because you donʼt know how early this infinity appeared, so, the whole result shall be dropped. The same is true for NaN.

    Please keep in mind that IEEE754 is IEEE standard, so, it is for adapted for ease of hardware implementation, at least for basic operations, with all related peculiarities and limitations. There are situations that IEEE754 is unsatisfactory: this includes higher precision, variable precision (see e.g. "rounding for shorter precision" == "von Neumann rounding"), interval arithmetic for error tracking, and so on. For them, software implementations shall be used.

    But, IEEE754 still provides some measures to cover the most common case set. It supports "exceptions" for all intermediate actions, (and, as already known here, values as INF and NaN), for cases it can't provide a result but still can express a discrepancy in a fast and cheap way. If you concern on all possible issues in calculations, you should, at least,

    • clear exceptions before calculations
    • do calculations
    • check both: final values (neither shall be INF or NaN until you are sure this fits your case), and exceptions (at least: overflow, divide by 0, domain error).

    Saying again, this doesnʼt cover all cases, but, typically, most of them.

    It's very situation-specific whether underflow and inexact exceptions are worth your attention. Most cases of inexact exception are simply inevitable and not important in physics-related calculations, but they are critical in decimal floating or fixed-point financial calculations. Underflow can be sign of serious issues like catastrophic cancellation.

    (The well-known Ariane 5 explosion is caused by double -> long int conversion, which is not a proper floating-point overflow discussed here.)

    There is no principal difference for the practical result - it was an overflow that was detected in time, but then respective exception was not handled.