1. ## Calculation loses precision

This is the code:

Code:
```double getTotal(){

return (double) BSALARY + getTAllowance() + getEAllowance() + getSOO();

}```
This is whats printed:

Annual allowance: 106770
Elecrorate allowance: 27300
Salary of office: 80077.5
Travel Allowance: 2040
-----------------------------------
Total: 216188

The total is the Annual allowance,Electorate allowance and Salary of office added to gether. As seen in the function getTotal()

The problem is where does the .5 in the Salary of office go?

2. Are all thoes values doubles, floats, integers or...?

3. They are a mix of floats and integers

4. do each of those functions do calculations as well? if getSOO() is returning a calculated float, you may get different decimals every time you call it...

from ibm
While suitable for many purposes, binary floating-point arithmetic should not be used for financial, commercial, and user-centric applications or web services because the decimal data used in these applications cannot be represented exactly using binary floating-point.
generally, doubles and long doubles are more precise than floats, but you can't count on that. from the standard:
Originally Posted by 3.9.1.8
The type double provides at least as much precision as float, and the type long double provides at least as much precision as double... The value representation of floating-point types is implementation-defined.

5. Ive taken out all floats and used doubles.

Because im still learning c++ but know Java. I have re-wrote my first java assignment in c++ using the exact same data types and return types as I did with the Java. And it works fine in Java.

This is weired, Ill guess Ill try some other things or just work around it...

6. that's because C/C++ is alot closer to your hardware than is JAVA. C/C++ is only as good as the hardware you run it on, unless you take extra steps to make sure it's better. For example, you could make a Float data type that has the precision you need. for example, maybe create a class that has two integers: one for the whole number, and the other for the decimal. By doing something like that and overriding all the necessary operators, you can make yourself a much more precise float, at the cost of more processing power and memory.

7. I wouldn't bet my home based on a claim that Java was actually doing it correctly either: the issues you're seeing are a fundamental property of floating point types (i.e. there will always be some sets of values where the sort of error you're encountering will become visible). The only thing we can say for sure is that it didn't happen with Java for the particular set of test cases you used.

The quotes that major_small gave from ibm are an indication of the issue: if you are serious about makinbg sure financial calculations work right, you will use some representation (eg dollars and cents, each as an integer) that is guaranteed to work correctly.

8. I see the point you guys are getting at. Like as in the value

Code:
`double money = 1.00`
Is actually stored as 1.0000000000000000000000000001

Based on the way the hardware is... And values are stored in memory? Or am I missing something completly?

9. well, yes and no

basically, the point is the binary numbering system was never meant to handle any increments less than a whole... for example... 00001 is 1 in decimal and 00010 is 2. It wasn't originally devised for anything like 1.5 because there aren't any decimals in real binary numbers.

Imagine it this way: I have a bushel of apples for sale, and you come up to me and ask for exactly 3.141592654 apples. It'd be impossible for me to give you exactly what you want, so I might just take a guess and give you 3.25 apples, or just 3, or maybe even 4.

now take my implementation with integers (whole apples). you know you want 3.141592654 apples, and you know that I'm not going to be able to give you what you want. So you ask me for 4 apples, and devise your own way to break that apple down.

10. An alternative to major _small's apples and ... well ... integers description.

Imagine you have the ability to store a decimal value to only 4 significant figures. Now, try to store a value that is exactly one third in it. The value you will store will be 0.3333, which is inexact as 1/3 is a 0.333333333333 (to an infinite number of places). Multiplying 0.3333 by 3 will not give 1, for example. The basic fact is that, if you have a finite representation of a real value, there are some actual numbers you can't store in it.

The only difference is that floating point works in binary (base 2) and has a fixed number of binary digits. So the same issue of storing values will arise: there will be some values that cannot be stored exactly in binary without an infinite number of binary digits. Unfortunately, two of the values that cannot be stored in a finite number of binary digits are 0.1 (one divided by the typical number of toes on a human being, in decimal) and 0.01. But 0.1 and 0.01 are both values that need to be handled precisely when working with most types of currency (eg dollars and cents, pounds and pence, etc etc).