0

I'm working on a safety critical, embedded program (in C) where I'd like to use IEEE 754 floating-point arithmetics (with NaN and Infs) for engineering calculations. Here I have two approach (afaik) to deal with floating point exceptions:

  • go to a permanent fault state if any exception occurs. This one is might more robust from error detection point of view, but bad for fault-tolerance/availability.

  • ignore exceptions, and check the final results whether they finite numbers (sucsessfull calculation) or NaN, inf (failed calculation). This solution is more fault tolerant, but it is more risky because outputs might accidentally be excluded from the check.

    1. Which would be a better solution in a safety critical system?
    2. Are there other options?
    3. If the complexity of the calculations does not allow the first solution (I can not avoid exceptions in normal usage) are the final checks enough or are there other aspects I should consider?
simon
  • 1,210
  • 12
  • 26
  • What Embedded Microprocessor? They're specific to the microcontroller/microprocessor in question. Also check out how to do lazy evaluations in long-series and what is meant by NaN and Inf inside your microcontroller/microprocessor's floating point unit – Aniket Inge Oct 18 '12 at 21:05
  • SH2, its FPU is IEEE754 conform, so I have both options. – simon Oct 18 '12 at 21:15
  • Probably makes sense to not treat all exceptions the same. Some may be harmless like denormalized underflow, while NaN or divide by zero may be completely unexpected – TJD Oct 18 '12 at 22:41

1 Answers1

1

  1. Which would be better in a safety-critical system depends on the system and cannot be answered without more information.

  2. Another option is to design the floating-point code so that no undesired behavior is possible (or can be handled as desired) and to write a proof of that.

  3. In general, checking final values is inadequate to detect whether exceptions or other errors occurred during computation.

In regard to 3, consider that various exceptional results can vanish in subsequent operations. Infinity can produce zero when used as a divisor. NaN vanishes in some implementations of minimum or maximum. (E.g., max(3, NaN) may produce 3 rather than NaN.) Analyzing your code might (or might not) reveal whether or not these things are possible in your specific computations.

However, an alternative to checking final values is checking exception flags. Most implementations of IEEE 754 have cumulative flags—once an exception occurs, its flag is raised and remains raised until explicitly reset. So you can clear flags at the start of computations and test them at the end, and, unlike testing final values, this will guarantee that you observe exceptions after they occur.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
  • 2: do you mean by limiting the inputs or how? That would be impossible to calculate the input ranges where these complex calculations surely won't fail. – simon Oct 19 '12 at 12:21
  • Division by inf may happen in the code, but the result is a good approximation most of the time. Otherwise I didn't considered relation operations on NaN. It could cause some problem. Your suggestion of checking the exceptions flags seems much more appropriate than checking the results. Thanks. – simon Oct 19 '12 at 12:29
  • @simon: 2 is open ended. It depends immensely on the application, on the specific computations involved. E.g., in some situations, the ideal functions computed are well behaved and never produce errors, but errors can occur because floating-point rounding perturbs the data. (E.g., if x is always not more than sqrt(3) in an ideal calculation, sqrt(3-x^2) is always real. But if floating-point rounding makes x slightly larger than sqrt(3), then sqrt(3-x^2) gets an error.) Sometimes you can design code to avoid these problems, perhaps by proving x is never too large or by explicitly limiting x. – Eric Postpischil Oct 19 '12 at 13:33
  • @simon: Zero may seem like a good approximation to a very small result, but consider evaluating `x/(2*y)` where previous operations have resulted in `x` and `y` each being 0x1p1023. Then `2*y` evaluates to infinity, and `x/(2*y)` evaluates to zero, but the mathematically exact value is 1/2. This is not a good approximation. – Eric Postpischil Oct 21 '12 at 10:29
  • Good example, thanks. I wrote "most of the time" because this could happen much fewer times than relation operation on nan in my code. – simon Oct 22 '12 at 10:14