Shulou(Shulou.com)06/02 Report--

This article mainly introduces the relevant knowledge of Java high-precision computing BigDecimal class case analysis, the content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this Java high-precision computing BigDecimal class case analysis article. Let's take a look.

What will we see if we compile and run the following program?

Public class Test {

Public static void main (String args []) {

System.out.println (0.05 to 0.01)

System.out.println (1.0-0.42)

System.out.println (4.015,100)

System.out.println (123.3 Compact 100)

}

You read it right! The result is indeed 0.0600000000000005 0.58000000000001 401.499999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

This problem exists not only in Java, but also in many other programming languages. In most cases, the results of the calculation are accurate, but a few more attempts (you can do a loop) can make an error similar to the one above.

Now I finally understand why there is a BCD code. This problem is quite serious. If you have 9.999999999999 yuan, your computer will not think that you can buy goods worth 10 yuan.

Special currency types are provided in some programming languages to handle this situation, but Java does not. Now let's see how to solve this problem.

Our first reaction to rounding is to round. The round method in the Math class cannot be set to retain a few decimal places, we can only do this (keep two places):

Public double round (double value) {

Return Math.round (value*100) / 100.0

} Unfortunately, the above code does not work properly. If you pass 4.015 to this method, it will return 4.01instead of 4.02, as we saw above. 401.4999999999999994

So if we want to do accurate rounding, we can't do any operations with simple types and we can't solve this problem:

System.out.println (new java.text.Decimal Format ("0.00") .format (4.025); the output is 4.02

[@ more@]

Big Decimal also mentions this principle in his book "Effective Java". Float and double can only be used for scientific or engineering calculations.

We need to use java.math.Big Decimal in business computing. There are four ways to build Big Decimal, and we don't care about using Big Integer? Enough to make those two, so there are two more.

They are: Big Decimal (doubleval) Translates a double into a Big Decimal.

Big Decimal (String val) Translates the String repre sentation of a Big Decimal into a Big Decimal.

The brief description of the API above is quite clear, and in general, the above one is easier to use. We may use it without even thinking about it. What's the problem?

When something went wrong, I found that there was a paragraph in the above detailed description of which method was sufficient: Note: the results of this constructor can be somewhat unpredictable.

One might assume that new Big Decimal (.1) is exactly equal to. 1, but it is actually equal to .10000000000000055511151231257827021181583404541015625.

This is so because. 1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length).

Thus, the long value that is being passed in to the constructor is not exactly equal to. 1, appearances nonwithstanding.

The (String) constructor, on the other hand, is perfectly predictable: new Big Decimal (".1") is exactly equal to. 1, as one would expect.

Therefore, it is generally recommended that the (String) constructor be used in preference to this one.

It turns out that if we need accurate calculation, we have to use String to build Big Decimal! The example in "Effective Java" is to use String to build Big Decimal.

But the book does not emphasize this point, which may be a small mistake.

The solution now we can solve this problem, the principle is to use Big Decimal and be sure to use String to build. But imagine if we were to do an addition operation.

You need to convert two floating-point numbers to String, and then generate Big Decimal, call the add method in one, pass in the other as a parameter, and then convert the result of the operation (Big Decimal) to a floating-point number.

Can you stand such a tedious process? Next we provide a utility class Arith to simplify the operation. It provides the following static methods, including addition, subtraction, multiplication and division, and rounding:

Public static double add (double v1 perfect double v2)

Public static double sub (double v1 perfect double v2)

Public static double mul (double v1 perfect double v2)

Public static double div (double v1 perfect double v2)

Public static double div (double v1, double v2, int scale)

Public static double round (double v.int scale)

This is the end of the article on "BigDecimal case Analysis of Java High Precision Computing". Thank you for reading! I believe that everyone has a certain understanding of the knowledge of "Java high-precision computing BigDecimal case analysis". If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.