Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m wondering what kind of errors I can encounter if I set /fp:fast instead of fp:precise?
I work under MSV10
I perform /,*,+,- operations on double with max digits equal to 8, like 1.4379294 (currency rate).
The same errors you always get with double calculations: you never get more than 15 significant digits after you convert the result to decimal, the rest are just random noise digits. The difference between /fp:fast and /fp:precise is what happens to those noise digits.
The /fp:precise option solves a problem with the x86 FPU, it stores intermediate results in the FPU registers with 80 bits of precision. Which can cause subtly different noise digit values if the intermediate value is kept in a register. With /fp:precise, the code generator is forced to flush those values back to memory, truncating them back to 64 bits. That’s slow, but does generate more consistent noise. Which matters if you commit the sin of comparing floating point values for equality without an epsilon.
Too much fud for most accountants, using a math library that counts with 10 fingers instead of 2 is a common solution. Which addresses the noise digit problem by eliminating the ones that are generated when you convert numbers from base 10 to base 2. Code will be slow, much slower than /fp:precise since all calculations are made in software without hardware acceleration. But typically not an issue in accounting applications.