c++ precision question

Quote:

---

Originally Posted by ninja9578

round() may not be part of the C99 standard, but I know that my math library has it in it. I've used it on occasion.

---

round() is not a standard C++ function.

Even if your library had it, it will not work all the time for all numbers if it uses double and float, traditional functions such as fmod() and fudge factors like adding 0.005, etc. This is what most "round" functions look like, and believe me, they will not work 100% of the time.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by ninja9578

Doing a C cast on any of the primitives to and integer will do an implicit round.

---

That is truncation, not rounding.

Bottom line -- rounding is not simple. I would dare say, it is impossible to write a 100% foolproof round() function using doubles and floats.

In the world of financial applications, it must be a guarantee that all rounding works 100% of the time, for all intermediate and final calculations, and for all numbers. The only way to achieve this guarantee is to not use doubles and floats. If you're off by .0001 in an intermediate calculation, and then you multiply that by 1,000,000 you will see the impact on a financial statement. A financial company could be taken to court and/or sued for giving incorrect numbers on a document they may send to a customer.

In the world of COBOL, there are types that do exact arithmetic, which is one reason why COBOL is still used in the financial industry. For C++ (and any other high level language that uses IEEE or IEEE-like floating point representation of numbers), you have to use special libraries (BCD, fixed point, or some other type of numerical representation) or code your own routines that bypass the usage of double and floats.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by nuzzle

This is a fundamental problem in computing. Not every number in decimal representation has an exact representation in binary (the internal representation used by computers). So the result of a conversion between decimal and binary will (most often) be approximate only. A conversion error is introduced.

The only solution is to round the result.

---

I'd like to expand on this a bit.

In principle the same problem exists even within a number system. For example the real number 1/3 cannot be exactly represented within the decimal system. It has to be rounded, that is be stopped after a certain number of decimal positions, like 0.3333333 (a float) or 0.33333333333333333 (a double).

This kind of fundamental number theoretical problems is something we've got to learn to live with when using computers. Sometimes the solution is to abandon floating point representations in favour of some other representation better suited for a certain application domain. For example currency has been mentioned. It's a very bad idea to use floating points to represent money.

But sometimes you've got no choise. In most physics applications for example there's no alternative to floating points. And sometimes the inexact nature of floating points is a blessing actually. It allows you to utilize very fast algoritms that are approximate. One example is the so called multipole algoritm. It's O(N) where other algorithms are O(N*lnN) at the best. This works only due to the fact that floating points are inexact. The multipole algoritm can stop when it has reached an accuracy that's better than the actual floating point accuracy. Its very high efficiency is based on the fact that floating points are inexact.

So there are pros and cons to floating points. It's not all bad. It's just a matter of accepting rounding really (results are exact only up to a specific bit).