Copyright (c) SEMM NL All rights reserved.
Author : Paul Hamaker. Part of JavaLessons.com
Add a double with value 5.4 to the value in result. Literal numbers with fraction are translated to double by the compiler.
Delete the result double's fraction by making an int copy, by CASTing to int.
Use the Math class' round method to produce a long rounded to the integer value 70 .
The literal 2 is translated to int by the compiler and, since chopped is an int, too, that makes this an integer division, causing the remainder, the fraction to be lost . Dividing by 2.0 ( a double ) would give a different result, as would (double)chopped / 2 , for that matter.
With doubles you have about 17 digits (depending on the value) to work with.
As shown in the output, a float offers less precision than a double. 7.0f makes it a float, 7.0 is a double. (float)result is a cast to float.
The java.lang.Math class contains lots of methods for numeric operations, like pow, abs, sin, cos, log, etc.
Highest or lowest value of two can be determined by using a max or min method. These are present for float, int and long, too, not just double.
As of Java5 we can insert this at the top of our code and thereby use short method-names, sqrt instead of Math.sqrt, and so on.
To handle a number's presentation we can use NumberFormat.
Minimum number of digits up to the decimal-point.
Number of digits for the fraction.
As you can see from the output, the resulting string contains a rounded value and possibly a comma instead of a decimal-point if your station's (country) setting so requires.
Just as 1/3 can not be expressed exactly in our decimal system, 0.333333...no end to it..., decimal 0.1 would be an unending repeating binary pattern. So 0.1 can only be stored in a float or double as a binary pattern that's VERY CLOSE to, BUT NOT EQUAL to, that value.( BigDecimal offers a way out, for it has the ability to store a decimal fraction exactly as it is.)
As the output shows, building calculations on results that are not exact, using doubles, may get you into trouble.
Depending on how large the numbers are, an alternative might be to do currency calculations in cents or tenths of these, using the long data type, offering ample room for 9 quintillion different values. An added bonus is better performance, as a rule.
Notice the letter 'L' to indicate a long, instead of an int.
If performance and space are the most important criteria, go for the primitives: long, int, double or float, but where large numbers are involved, exact results are needed and exact decimal fractions, as with financial calculations, go for java.math.BigDecimal.
Construction using a String is exact. If you use a double as a parameter to a constructor, chances are, the double's inherent lack of precision winds up in the BigDecimal, giving it a bad starting-point. So, try to construct BigDecimals with a String or, failing that, an int or long.
An alternative might be, to use this method, which actually uses a String representing the double to construct a BigDecimal with.
An added advantage of BigDecimal ( hence its name ) is, that you can do calculations involving (very) large numbers, which is BigInteger's forte, too.
Calling BigDecimal's add method. Just as with String's methods, the original instance is not changed, but a reference to a new BigDecimal instance is returned, containing the result. Just calling bd.add... won't suffice.
Some more calculations,...
where these parameters indicate: 3 digits to the right of the decimal-point, the 'scale' desired, plus the rounding mode, in this case, >.0005 upwards, <.0005 down, =.0005 up or down.
Since Java5 we can determine the precision as a number of digits, plus how we want the result rounded, by using java.math.MathContext . It can be passed as a parameter to BigDecimal's constructors and methods.
Sensible choice, often, performance-wise. HALF_EVEN is bankers' rounding mode.
As of Java5 we shouldn't use BigDecimal's constants anymore, like BigDecimal.ROUND_HALF_EVEN, but use RoundingMode instead .
Values in BigDecimals are stored somewhat along the lines of packed decimals, BCD ( where a digit takes up a half-byte ), but in this case compressed.