c++ precision question

Hello everyone,

I have a question about doing arithmetic with C++. Say I have something like:

(71/10) - 7.0 and it gives me something like: 0.0999999. How can I get it to give me 0.1.

Cheers,
xarg

Quote:

---

Originally Posted by xargon

Hello everyone,

I have a question about doing arithmetic with C++. Say I have something like:

(71/10) - 7.0 and it gives me something like: 0.0999999. How can I get it to give me 0.1.

---

You have to explain more. What do you mean by "give me 0.1"? Do you just want to output 0.1? Or to use 0.1 in further calculations?

If you're trying to use 0.1 in further calculations, using regular C++ floating point types such as float and double will not work reliably in terms of exact calculations. Either use normalized integers and do calculations, or get a fixed point math library.

Regards,

Paul McKenzie

You can't with the built in floating point types
Numbers that are a fixed number of places in decimal may be an infinite number in binary, and that's what the computer is working with at the lowest level.

In your case, 0.1 is not representable as a finite length floating point binary number.

Well here is an article on CG with the information you are looking for:
http://www.codeguru.com/cpp/cpp/algo...cle.php/c12097
As JohnWessex mentioned it is a fixed point library.

You need to run your code on a PPC or a SPARC Processor, they have much higher floating point accuracy. Intel is notoriously poor when it comes to that, or else use OpenCL and use the graphic card's floating point calculator. None of them will give you perfect results every time, but they're better.

Something I noticed, you do know that 71/10 will give you 7 right? That's an integer division.

Quote:

---

Originally Posted by ninja9578

or else use OpenCL and use the graphic card's floating point calculator.

---

All but the newest graphics cards will only support single-precision float calculations. I don't know whether OpenCL tries to do any double-precision emulation on the older cards, but if it does, that will slow it down considerably.

I wasn't recommending it anyway, I don't even think OpenCL has been released yet for anything other than the Mac. I was just saying it's a possibility.

Accuracy with floating point is always very difficult, I had to write a floating point library from the ground up once, Maybe I can find it and post it for you.

Quote:

---

Originally Posted by xargon

Hello everyone,

I have a question about doing arithmetic with C++. Say I have something like:

(71/10) - 7.0 and it gives me something like: 0.0999999. How can I get it to give me 0.1.

---

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 wouldn't say that's the only solution. You could use a fixed-point representation in some cases. This is typically what is done with money----just work in terms of cents.

Quote:

---

Originally Posted by Lindley

I wouldn't say that's the only solution. You could use a fixed-point representation in some cases. This is typically what is done with money----just work in terms of cents.

---

Rounding is the only way to handle the conversion error problem associated with floating point representations. Not using floating points isn't a solution to this particular problem.

The original question:

Quote:

---

Originally Posted by xargon

(71/10) - 7.0 and it gives me something like: 0.0999999. How can I get it to give me 0.1.

---

This would do it:

Code:

---

cout << 71/10 - 70/10 << "." << (71 - 70) % 10 << endl;

---

Of course, this only works because the output representation is base 10 and the divisor is 10.

Not too sure you which of the following you want:

a) If you round off and use in further calculations, then you could do this:

I got the below from the internet, round is a function defined in cmath, it rounds off to an integer but you can round off to a specific precision by dividing again my a multiple of 10 as shown below:

Code:

---

#include <iostream>
#include <cmath>
using std :: cout;

int main()
{
       
    double x, y;
       
    x=3.1415927;
        y = round(x*10000)/10000.0;
       
    cout << "y = " << y << '\n';

    return(0);
}

---

b) If you just want to display the number to a certain precision but still needed to retain the number for calculations, then you could use the following functions on cout:

Code:

---

cout.precision(2); //set your own precision, this is only formatting the output
cout.setf(ios :: fixed); //Setting to fixed point notation

---

you could even set it to scientific notations, you can set and unset flags, there is a whole bunch of options.

Quote:

---

Originally Posted by Muthuveerappan

I got the below from the internet, round is a function defined in cmath,

---

There is no such function as round() in <cmath>.

Secondly, no matter how hard a programmer will try, due to the nature of floating point numbers, no round() function can be written that will work 100% of the time that uses traditional doubles and floats.

If you have ever worked in the financial industry where exact calculations are required, usage of float and doubles are prohibited in the programs written for these institutions. Instead, special libraries that use fixed point, or even a different computer language (i.e. COBOL) are used to ensure that calculations come up with no round off error. I used to work in the insurance industry, and in no way could doubles be used.

If rounding were possible by just using float and double, there would be no need for such libraries and differing technologies, and such a function would exist in the C++ language library. It doesn't exist.

Regards,

Paul McKenzie

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. I use MinGW

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

Code:

---

float x = 1234.56;
int i = (int)x;
cout << i << endl;

---

Quote:

---

Originally Posted by ninja9578

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

---

That will do a truncation, which is a bit different from rounding. For instance, 1.75 will become 1 rather than 2 as you'd expect. For rounding, you'd need to do

Code:

---

int signum(double x)
{
    return (x > 0) - (x < 0);
}

int round(double x)
{
    return (int)(x + signum(x)*0.5);
}

---

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).