Possibly an advanced java question

[errigour]

I have a java compiler and Im using a double intiger called Experience
and when compiled and run the double intiger does not hold intiger values
that are mathameticle. Like 1.5 - 1.4 will equal .100000000000000000009
and 5/3 will equal 1.0. and 1.5x 1.4 doesnt equal 2.1. Is there something I am doing wrong with double intigers? Is it the compilers fault? Could it be something thats wrong with my computer and the compilers I am using are not tat fault?
Anyways double 1.5 + 1.4 does equal 2.9 so.

[Kloschüssel]

That's definitely amongst the top 10 things that a programmer should know. A good start is the RFC IEEE 754.

[ananthap]

Basics:
JAVA assumes integer arithmetic results in integer value. So 5/3 is 1. Try 5.0/3.0.

also, in float, double (not double integer), you have to use the most significant characters.

To conclude, the behaviour is OK. You have to enhance your program appropriately.

[Cabhan]

Allow me to be a bit clearer.

In lots of programming languages, "double precision values" (aka doubles) cannot store certain values perfectly. The RFC that Kloschussel mentioned describes the format of a floating point number. Some values cannot be represented, and some math is not done perfectly (there are values for x and y where x - y = z, but y + z != x).

Whenever you are using doubles, you must build in a certain tolerance for error.

Java lets you get around this problem by using the BigDecimal class:
BigDecimal (Java 2 Platform SE 5.0)

Other programming languages have similar libraries that accomplish this. These classes are not true double precision values as specified in the above RFC, and do a lot of their arithmetic in software, not hardware, so they are much less efficient. However, they do guarantee arbitrary precision and correct math behaviour.

[Kloschüssel]

@ananthap not completely unrelated as the symptoms are the same, but the problems mainly araise due to rounding of "odd" numbers that cannot be stored using a 2-base representation with a limited number of bits. some example is the decimal number 0.1, which would be the binary equal 0.010101010101..

This representation of numbers is suited well for:

* storing numbers from the set of natural numbers (N+) [1]
* work fast with numbers from a distinct subset of the set of real numbers (R+), as there are routines built in hardware that can do those operations really fast without round-tripping the cpu.

If one wants exact representation of numbers out of the set of real numbers (R+) with the only limit mentioned in [1], one has to adapt the mathematical model behind it.

--- excursion into the theory of mathematics, for those who are interested

This can easily be achieved by extending the algebra. The mathematical name for it is "Finite Field". There one can use a tuple to represent numbers. The idea behind this is mainly as common as to represent the number 0.33333.. in the decimal system: write it as a fraction: 1/3.

(a, b) which represents the 1-tuple number a/b

Then we just lack the mathematical operations that define a overload of operators:

Inversion:
- (a, b) = (-a, b)
(a, b)^-1 = (b, a)
Addition:
(a, b) + (c, d) = (a*c + c * b, b*d)
(a, b) - (c, d) = (a, b) + (-c, d)
Multiplication:
(a, b) * (c, d) = (a*c, b*d)
(a, b) / (c, d) = (a, b) * (d, c)

Obviously one has to implement the automatic reducing (or simplifying) of the 2-tuple (fraction) by finding the greatest common divisor. See the euclidean algorithm.

Unless one day one builds cpu's with an ALU that supports fractions, the performance of these operations are going to be worse than those built-in hardware by far! This finite field's borders are the smallest and biggest value of the storage you use for the components of the fraction. i.e. if you use an int for the components, you have the distinct set of values:

min = (1, max(int))
max = (max(int), 1)

For further information visit your favorite universities first semester courses.

[1] one still cannot store hilarious huge numbers as long as computers have a limited amount of memory (i.e. you can store only as much digits as you have free memory)