0

I heard that C/C++ has a problem with the management of the float point numbers. I've implemented a simple program to try it. It consists in a change machine: the user enter the quantity to charge and the quantity paid, and the program calculates the number of coins for each coin type to give as change.

Here is the code: Link to my google drive folder with the code

The thing is, when you insert a non-integer value, the program enter in a loop and never ends. I've printed the content of the variables to find out what's going on, and, somehow, from a 2 decimal value let's say: 0.10, the program changes its value to a 0.0999998. Then, the remaining change to be processed never is 0 and it enters in a infinite loop.

I've heard that this is due to the machine representation of the float point numbers. I've experimented the same either windows and Linux; and also programming it in Java, but I don't remember to have had the same issue in pascal.

Well, Now the question is: what is the best workaround for this? I've thought that one possible solution is using fixed point representation, via external libraries as: http://www.trenki.net/content/view/17/1/ or http://www.codef00.com/code/Fixed.h . Other maybe is to use a precision arithmetic library as: GMP

yizzlez
  • 8,757
  • 4
  • 29
  • 44
Akronix
  • 1,858
  • 2
  • 19
  • 32
  • 2
    The code should be posted here. Otherwise the question has no permanent value and is liable for deletion. – user207421 Mar 29 '14 at 15:16
  • 4
    Don't work with floating-point quantities of dollars, just work with integer quantities of cents, simple. – enhzflep Mar 29 '14 at 15:18
  • Akronix, next time do not post a link. If there is too much code, create a testable example. – yizzlez Mar 29 '14 at 15:18
  • 1
    Fixed point works well for money, not so much for other problem domains. – Mark Ransom Mar 29 '14 at 15:18
  • @MarkRansom but which other domains require exact calculations – mmmmmm Mar 29 '14 at 15:19
  • If you have 2 float variables, e.g num1 and num2 and you are writing like this num1 == num1. Then this may be the problem. You should never do this for float numbers. – Ali Raza Mar 29 '14 at 15:21
  • 1
    @Mark there's lots of times where `==` not working will mess you up. – Mark Ransom Mar 29 '14 at 15:21
  • Search this site and the Internet with terms like: `numerical analysis`, `numerical methods`, and `c++`. – CPlusPlus OOA and D Mar 29 '14 at 15:32
  • 1
    You might want to read [What Every Computer Scientist Should Know About Floating Point Arithmetic](http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html) – Tony Delroy Mar 29 '14 at 15:37
  • Ok, my question is already answered with all the information collected from you guys. Specially from this question: [Is floating point math broken?](http://stackoverflow.com/questions/588004/is-floating-point-math-broken.) Although my question was looking for a workaround for this issue. One other possible good solution which works for me is round the float number before to be compared. Thank you! – Akronix Mar 29 '14 at 18:40

1 Answers1

4

Neither C nor C++ has a problem with floating point values. You as the programmer are trusted to use floating point appropriately in any language supporting it.

While integer variables cannot store fractions nor out of bounds values, floating point can only store a specific subset of fractions. A high quality floating point implementation also gives tight guarantees for the accuracy of calculation.

Floating point numbers are not rational numbers, which would need infinite space to store reliably.

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
  • 1
    More specifically, you are asking your computer to store 0.1 in a float. IEEE Float and double are binary floating-point formats. They can store 97, 0.25, and 7.3125 with perfect accuracy, but they cannot store 0.1. This is for the same reason that base-10 numbers cannot store 1/3. Some languages hide this from you, but no language can hide it from you perfectly. The problem is not with C/C++. – Bruce Dawson Mar 31 '14 at 05:24