What claims, if any, can be made regarding the accuracy / accuracy of floating point calculations?

Question

I am working on an application that does a lot of floating point computing. We use VC ++ for Intel x86 floating point with double precision. We claim that our calculations are accurate up to n decimal digits (now 7, but allegedly 15).

We make a lot of efforts to check our results compared to other sources, when our results change a little (due to code refactoring, cleaning, etc.). I know that many factors affect overall accuracy, such as the state of the FPU control, the compiler / optimizer, the floating-point model, and the general order of operations (i.e. the algorithm itself), but given their inherent uncertainty in FP calculations (e.g. , 0.1 cannot be represented), it seems invalid to require any particular degree of accuracy for all calories.

My question is this: is it really possible to claim the accuracy of FP calculations without any analysis at all (for example, interval analysis)? If so, what claims can be made and why?

EDIT:

So, given that the input data is accurate, for example, in ten-digit places, can the result of any arbitrary calculations be guaranteed, given that double precision is used? For example, if the input has 8 significant decimal digits, the output will have at least 5 significant decimal digits ...?

We use math libraries and do not know any guarantees that they can or cannot make. The algorithms we use are not necessarily analyzed for accuracy in any case. But even taking into account a specific algorithm, the implementation will affect the results (for example, simply by changing the order of the two add operations). Is there any inherent guarantee when using, say, double precision?

OTHER CHANGE:

We empirically confirm our results in comparison with other sources. So, are we just lucky when we achieve, say, 10-digit accuracy?

Answer 1

If your code does not use only the basic operations specified in IEEE 754 (+, -, *, / and the square root), you don’t even know how many precision losses each call to library functions is outside your control (trigonometric functions, exp / log ,. ..). Functions outside of core 5 are not guaranteed and, as a rule, are not exact with 1ULP.

You can do empirical tests, but that they remain ... empirical. Do not forget that your software is not guaranteed in EULA!

If your software was security critical and did not invoke library math functions, you can consider http://www-list.cea.fr/labos/gb/LSL/fluctuat/index.html . But only critical software is worth the effort and has the ability to fit into the limitations of analyzing this tool.

It seems like after editing, you are mostly worried about how your compiler does something in your back. This is a natural fear to have (because, as with mathematical functions, you are not in control). But this is unlikely to be a problem. Your compiler can calculate with more accuracy than you requested (80-bit extensions when you requested 64-bit doubles or 64-bit doubles when you requested 32-bit floats). This is permitted by the C99 standard. In the round to the nearest, this can lead to double rounding errors. But this is only 1ULP, you lose, and therefore it is not often that you do not need to worry. This can be bewildering, as in:

float x=1.0; float y=7.0; float z=x/y; if (z == x/y) ... else ... /* the else branch is taken */ 

but you were looking for problems when you used == between floating point numbers.

When you have code that specifically performs cancellation, for example, in the Kahan summation algorithm:

 d = (a+b)-ab; 

and the compiler optimizes this value at d=0; you have a problem. And yes, this optimization "as if the operation of the floats was associative" has been seen in general compilers. not allowed no . I think the situation has gotten better. Compiler authors have become more aware of the dangers of floating point and are no longer trying to optimize so aggressively. Also, if you do this in your code, you will not ask this question.

Answer 2

As with all such questions, I should simply answer with an article What Every Computer Scientist Should Know About Floating-Point Arithmetic . This is absolutely necessary for the type of work you are talking about.

Answer 3

Short answer: None.

Reason: You proved (yes proved) that you do not lose accuracy when you go? Are you sure? Do you understand the intrinsic accuracy of any library functions that you use for transcendental functions? Have you calculated the limits of additive errors? If you use an iterative algorithm, do you know how much it converged when you leave? It's complicated.

Answer 4

Given that your suppliers of computers, compilers, runtime libraries, and operating systems do not make any such statements about accuracy With a floating point, you should take this as a warning that your group should be inclined to make claims that could be subject to stringent checks if clients have ever brought you to court.

Without a formal review of the entire system, I would have avoided such claims. I am working on scientific software that indirectly affects human security, which is why we have considered such things in the past, and we do not make such claims.

You can make useless claims regarding the accuracy of double-length floating point calculations, but that would be practically useless.

Ref: ACM Transactions floating point test traps in programming languages ​​and systems 30, 3 (2008) 12

Answer 5

No, you cannot make such a claim. If you want to do this, you will need to do the following:

• Hire a numerical specialist to analyze your algorithms.
• Either ask the developers of the library and the compiler to open their sources for the said expert for analysis, or ask them to subscribe to the hard semantics and error limits.

A double-precision float usually contains about 15 decimal digits, but there are too many ways to lose part or all of this accuracy, which are too thin for a non-expert diagnostic to make any claim as you would like to state.

There are relatively simpler ways to keep errors in error, which will allow you to state the accuracy of any specific calculations, but the statement about the accuracy of all calculations performed with your software is much higher.

Answer 6

The double-precision number on the Intel processor is slightly better than 15 significant digits (decimal).

A potential error for a simple calculation is in the ball n / 1.0e15, where n is the serial number of the number (s) you are working with. I suspect that Intel has specifications for the accuracy of processor-based FP calculations.

A potential error for library functions (e.g. cos and log) is usually documented. If not, you can look at the source code (for example, the source thr GNU) and compute it.

You calculated error bars for your calculations as well as for manual calculations.

Once you do this, you can reduce the error by reasonably streamlining the calculations.

Answer 7

Since you seem to be worried about the accuracy of arbitrary calculations, here's what approach you can try: run your code with different rounding modes for floating point calculations. If the results are pretty close to each other, you're probably all right. If the results are not close, you need to start worrying.

The maximum difference in the results will give you a lower bound on the accuracy of calculations.